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

[Stefan Seyfried]

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 :-)

> 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.
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.

> Which brings me to...
> 
> On Wed, 2006-10-11 at 15:06 +0200, Stefan Seyfried wrote:
> > I have my doubts that this will work anywhere besides a SUSE system since
> > it makes some assumptions about the layout of /boot/grub/menu.lst and about
> > the names of the kernel binaries, and i do not think that these are valid on
> > other systems.
> 
> *nod*.  This is basically the sort of script that I'd say is the "#1"
> case above.  Which is to say, I'd be fine with the grub hook in pm-utils
> being:
> 
> . /etc/pm/functions
> 
> fedora-prepare-grub() {
>   [very small script that calls grubby to do the real work]
> }
> 
> fedora-resume-grub() {
>   [very small script that calls grubby to do the real work]
> }
> 
> suse-prepare-grub() {
>  [very small script that calls your script to do the real work]
> }
> 
> suse-restore-grub() {
>  [very small script that calls your script to do the real work]
> }
> 
> PREPARE=$(find-vendor)-prepare-grub
> RESTORE=$(find-vendor)-restore-grub
> 
> RETVAL=0
> case "$1" in
>   hibernate)
>     [ "$(type -t $PREPARE)" == "function" ] || break
>     eval $PREPARE
>     RETVAL=$?
>     ;;
>   thaw)
>     [ "$(type -t $RESTORE)" == "function" ] || break
>     eval $RESTORE
>     RETVAL=$?
>     ;;
>   *)
>     ;;
> esac
> 
> exit $RETVAL
> #---- end script ----
> 
> and then in /etc/pm/functions we'd put something like:
> 
> get-vendor() {
>   if [ -x /etc/pm/get-vendor ]; then
>     /etc/pm/get-vendor
>   else
>     echo unknown
>   fi
> }

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.
 
> 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 :-)

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 :-)
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out."