[Pm-utils] Some thoughts about some of the hooks

[Peter Jones]

On Fri, 2006-10-20 at 13:55 +0200, Stefan Seyfried wrote:
> On Thu, Oct 12, 2006 at 11:08:48AM -0400, Peter Jones wrote:
> > On Wed, 2006-10-11 at 10:21 +0200, Holger Macht wrote:
> 
> > > So I think we should remove it if (1) we can't manage to 
> > > find _one_ generic way and because (2) ideally it should be in
> > > the grub package.
> > 
> > I'm not sure I totally agree with this.  Basically, there are 2 pieces
> > of functionality here:
> > 
> > 1) "find our current kernel and make grub boot it once without
> >    waiting for input".  This should be functionality provided by
> >    something other than pm-utils.  It could be a script in the
> >    distro's grub package, or another package entirely.  (Undoing
> >    this setting goes here as well)
> 
> Ok
> 
> > 2) actually do it during hibernate.  This could come from upstream,
> >    a distro's hooks tarball, or from a distro's grub package, or even
> >    someplace else entirely.  It's up to the distro.
> 
> Ok. And probably 1) and 2) will happen in the same hook, since otherwise
> you need a place to store the knowledge obtained by 1) for use by 2) which
> IMO makes stuff more complicated for no real gain. I might of course have
> missed something :-)

1 is _in_ the hook.  2 is a program run by the hook.

> > Now, obviously both of these are up to the distro.  But I'd _like_ to
> > provide at least a reasonable prototype for #2 in upstream pm-utils,
> > which distros can choose to actually use or not.
> 
> Probably an "examples" or "contrib" directory would be a place to put such
> stuff. From my experience with this stuff in powersave, it is really hard
> to make it work on more than one distro without jumping through hoops.

Well, that's the point -- the simple part, "1", is small enough that
it's not terrible to simply have the code for every distro that wants it
in the default hook.  The complicated part is provided by the distro in
a separate executable.

> And once we define (and publish) the interface, maybe just upstream grub
> will provide a suitable hook (or maybe a "grub --dry-run \
> --gimme-the-next-booting-kernel" option, which would make it work on all
> distros.

I wouldn't hold my breath for this to happen...

[quoted script ripped out]
> but is there any benefit versus just every distro shipping its own hook?
> We could collect them all in CVS in a "distro/debian, distro/fedora,
> distro/suse, distro/gentoo, ..." directory structure and _if_ we find out,
> that everybody is basically doing the same, it would still be easy to
> consolidate.

The benefits I see are:

1) we don't have to worry about duplication as much this way, since
everything is in one file
2) there's plenty of example code at one place for interested hackers to
look at, and it might give one of them a good idea to pitch at the rest
of us
3) it's still crystal clear which distro is doing which way.

Also, I'm still unclear as to if, in the more general case (i.e. not in
the context of just this hook), the drawback of possible duplication is
worth it compared to the per-distro hooks directories.  In most cases it
seems all distros are pretty close together; there are a couple of hooks
where that's not the case, but I don't actually think it'll wind up
being that many.

Basically, I don't think it's worth introducing such an easy way for us
to mess up unless it becomes clear that it makes things significantly
easier across lots of hooks, rather than just one or two.

> > If you have suggestions for this (or more example scripts that would use
> > some generic logging hook, just so I know what sort of thing you're
> > looking for), that'd be good.
> 
> I would for example log every running hook. The loaded modules before suspend
> (this can easily done in a "collect-info" hook), the stopped services, the
> modules we unloaded, that we actually invoked the suspend in the kernel.
> During resume, basically the same, just in reverse.
> 
> I also have a pretty trivial patch in mind to achieve this, i'll just have
> to put the idea into code. Will happen soon :-)

Done.

> This logging might sound unimportant, but from debugging lots of suspend
> problems, i know that you cannot log enough. Right now the failure mode of
> pm-suspend is "it does nothing and it outputs nothing". Not good :-)

Yeah, we definitely need to work on making things more debuggable by
more users.

-- 
  Peter