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

[Peter Jones]

On Thu, 2006-10-05 at 18:50 +0200, Stefan Seyfried wrote:

> 01grub:
> - should not be the first one that is called. If something fails and we do
>   not actually suspend, the user will have a surprise at the next reboot.

I don't think this matters much assuming we make the next bullet point
work ;)

> - we need to restore the original behaviour in case the suspend fails.

Yes.

> - should not be in the pm-utils package but in the grub package.

Generally we've been ignoring this for a lot of stuff until everything
matures a bit more.

> 05led:
> - the kernel should actually do this when platform mode is used. It seems
>   to behave strangely since some versions, though, so i will investigate
>   this.

Eh?  Kernel really doesn't know we're doing suspend operations until
*well* after it's useful to have the blinky lights.

> 10NetworkManager
> - should be in NM package
> - shouldn't the "session daemons" actually do this? Send a "going to suspend"
>   signal which NM (and others) will listen to?

No -- Using NM does not imply that you're using a graphical setup, which
is generally where those session daemons come from.

> 20video:
> - should be the last thing that is done before suspend, so it will be the
>   first thing that runs after resume. Otherwise users that switch the console
>   too might cause trouble.
>   This is one reason why s2ram has everything in one binary, to make it less
>   likely that somebody else messes around with the video hardware. Still not
>   perfect (it should be in the kernel), but we might get it there with some
>   help from the uswsusp infrastructure (freeze everything but s2ram).

I'll ignore this bit for now in favor of the other threads about it.

> 49bluetooth:
> - what is this good for? It is much easier (and safer) to just virtually
>   unplug the BT dongle before suspend (by rmmod'ing hci_usb) and replugging
>   it after resume. I never had a single problem with that.

This is basically a hack because the BT modules/daemons have spent so
much time being completely hosed.  Every bug you can imagine has shown
up in them at some point in time.  If distros think they have working
support, they're certainly not compelled to use all of the scripts
pm-utils provides.  They're just defaults.

> 50modules:
> - different lists of modules for suspend / hibernate might be a good idea
>   (yes, i had a machine with r8169 that needed to be unloaded before suspend
>   to RAM otherwise the machine would lock up hard, but needed to stay during
>   suspend to disk, otherwise the network was dead. The driver is fixed now.
>   :-)

Generally modules have been broken for both if broken for either.  There
might be some exception, but basically this is there to fix broken
modules, so the real answer is to fix the modules and make this module
list be empty. ;)

> 90clock:
> - setting the hwclock before suspend is only needed if your cmos clock runs
>   badly wrong. If you do not have ntpd running (no network, notebook), then
>   it might make things even worse. Resetting system time after resume from
>   the cmos clock is not needed, the kernel does this already.
>   (We had this option in powersaved since up to 2.6.7(?) the kernel did not
>   do this correctly. After the kernel was fixed, we set the default to "off".
>   I never had a bugreport about it ever since, so i wanted to remove it from
>   powersaved anyway).
> - just waiting 20 seconds does not ensure that NetworkManager etc. has come
>   back.

Yep, it's a racy kludge.  But ntpd sucks ass and can't deal with having
no network sanely.

>   -> this should be done from a networkmanager-dispatcher-skript.

No, ntpd should just be fixed.

> This is what i saw after a short look. There might be stuff that i simply
> don't understand, but before i start adding more stuff to the hooks directory,
> i want to know if i am on the right track :-)

In general, yes.

-- 
  Peter