[Pm-utils] [RFC] [patch review] Hook independence and security fixups, part 1

[Victor Lowther]

On Sun, 2008-02-03 at 13:02 -0800, Dan Nicholson wrote:
> On Feb 2, 2008 6:26 PM, Victor Lowther <victor.lowther at gmail.com> wrote:
> >
> > hm?  removing zzz is quite relevant, all it did was actually perform
> > the suspend/hibernate/whatever, and with this patch we no longer need
> > it.
> 
> Except you didn't actually put the sync back anywhere.

Ah, the syncs.  Wasn't thinking about those.

> > Heh, I guess I come too much of a functional programming background --
> > passing a curried function to another function seems like a perfectly
> > obvious and noncontroversial thing to do. sh just has weird syntax for
> > doing it. :)
> 
> With a real programming language, I'd feel more comfortable "passing a
> function pointer", but it seems sketchy in sh. More importantly, I
> just doing think having a plugin type architecture is worth that added
> complexity.

I do not see how you can really say that -- we already have a plugin
architecture for the hooks that uses pretty much the same type of API as
this one, even if it was not really documented until I added
HOWTO.hooks.

> I think we _do_ want to have all of that in the pm-utils repo. Adding
> an API to pm-utils is just not worth the effort of properly designing
> it. How are we going to enforce this API? 

We don't, we just document it clearly, and if a module breaks people
complain.  Just like with the hooks.

> Do we know all the interfaces that would be needed?

Well, I can think of three:
* Called with no parameters, do whatever suspend action you implement,
and return the name of the appropriate resume action on stdout (this is
to handle suspend-hybrid correctly -- going in, we do not know whether
we will need to perform resume actions or thaw actions after we wake up,
so we let the hook tell us).
* Called with "inhibit", do whatever you would normally do, except don't
actually sleep.  
* Called with "check", exit with 0 if the suspend action you implement
is supported on this machine, 1 if it is not.

> > Hmmm... with the modular backend, we can let Nigel, Rafael, and the
> > distros worry about making sure that the actual backend sleep/wakeup
> > modules do The Right Thing without having to worry about our code, and
> > we can more easily adapt to whatever Next Great Revolution in
> > suspend/resume technology comes about.
> 
> They can also "do the right thing" by adding 40 line patch to
> pm-utils. IMO, having an API is overkill, adding complexity and
> codepaths to a conceptually simple idea.

Hmmm... I do not see it as overkill, merely as refactoring and
formalizing something that was spread out across the codebase and not
very well documented.

> --
> Dan