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

[Holger Macht]

On Thu 12. Oct - 11:08:48, Peter Jones wrote:
> 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
> }

Because of all this, it seems that we'll still need some distro specific
hooks, distro specific decisions, etc. So wouldn't it actually make sence
to add some distro hook directories to CVS? Something like

  fedora-hooks
  suse-hooks
  gentoo-hooks
  ...

So that every distro has one common place to work on and in the same
project, and people who are willing to try pm-utils can have a look at
different implementations for some kind of the same problems. But of
course we have to pay attention that we don't duplicate code.

So the best feature set that works for all can be in the generic hooks
directory, and more special things can be in the distro hooks directories.
And distros can decide on their own which hooks to install, but they get
it from one common place.

Regards,
	Holger