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

[Peter Jones]

On Wed, 2006-10-11 at 10:21 +0200, Holger Macht wrote:

> > For now, I'd just as soon leave this here, but make it call some script
> > we can mutually decide on to set/unset the next boot option.
> 
> Well, I think pm-utils should just provide the lowest common denominator
> all distros can use out of the box. We will have a extra tarball
> containing hooks which adds extra functionality, and that's something
> every distro will need.

Well, yes and no.  I think we're responsible to provide the lowest
common denominator, but we should provide the best feature set we can
reasonably muster.  More on this below.

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

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.

Which brings me to...

On Wed, 2006-10-11 at 15:06 +0200, Stefan Seyfried wrote:
> On Tue, Oct 10, 2006 at 07:53:40PM -0400, Peter Jones wrote:
> 
> > > And since every distro has a little bit different tweaks for grub (or
> > > maybe just plain simple naming conventions for the boot entries or such),
> > > i think the grub hook belongs in the grub package.
> > 
> > For now, I'd just as soon leave this here, but make it call some script
> > we can mutually decide on to set/unset the next boot option.
> 
> On SUSE i can just copy /boot/grub/default to a safe place and restore it
> during thaw(), and everything will be fine. I have however no idea if this
> is a solution that only works due to some suse-specific grub patch or if
> this is a generic solution.

(I think this is how upstream grub actually is as well, but it's not
what's in our packages because of historical reasons involving when we
added our patch and when the change actually went upstream :/ )

[ hook explanation removed]

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

> This is also a pretty raw port of the corresponding powersave script, since
> pm-utils do not have any logging / debugging infrastructure yet, every hook
> has to roll its own for now.

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.

> So this is just a "look how i think that it could be done" and not a "please
> include" :-)

Right ;)  So what I'm saying is I'm ok incorporating very small
vendor-specific chunks, but the heavy lifting should be done in a vendor
specific script we call out to when there's not one widely-accepted way
to do things.

-- 
  Peter