[Pm-utils] Cutting down on unnecessary hooks

Dan Nicholson dbn.lists at gmail.com
Wed Nov 26 11:31:18 PST 2008


Recently I was debugging some suspend issue and was using bare `echo
mem > /sys/power/state'. Turns out, it was much faster than using
pm-suspend. That got me thinking that the pm-utils hooks must be
taking a long time. Looking at the current default hooks, it seems
that some are useless or less than optimal.

49bluetooth: Disables/reenables IBM bluetooth.
Shouldn't the kernel handle this if it's necessary? If it does, can we
bail out if the kernel is new enough?

50ntpd: Stops/starts ntpd.
This seems completely wrong. First, ntpd surely knows how to handle
the network going away suddenly. Suspend is not the only time when the
network connection could be lost. Second, if it is deemed that
stopping ntpd when the network goes away is necessary, wouldn't this
be better handled by a NetworkManager dispatcher script? NM actually
knows when the network is available, which is much better then the
total hack here to sleep 20 seconds in the background in the hopes
that the network will be available later.

55battery: Make HAL rescan the batteries on resume.
Shouldn't gnome-power-manager (or whatever HAL using policy agent) be
the one to tell HAL to do this? And since we're not doing anything
with the reply, why do we need to specify a timeout?

65alsa: Store/restore the driver state.
The comment here even says that newer ALSA doesn't need this. Can we
bail out on newer kernels? Or drop it completely since these bugs
should be fixed if they exist?

90clock: Syncs to/from the hardware clock.
Is this necessary? I honestly don't know.

94cpufreq: Sets the cpufreq governor to performance for suspending if available.
I don't know why this would need to be done at all. If there are bugs
suspending under certain governors, those bugs should be fixed. At the
very least, I think TEMPORARY_CPUFREQ_GOVERNOR should be unset by
default and the hook should bail out in that case. This should only
ever be a temporary workaround like SUSPEND_MODULES.

95led: Blink the suspend LED on IBM.
It would be cool if thinkpad_acpi did this on its own, but I do
appreciate the blinking on my thinkpad.

90chvt, 99video: It would be great if these would die someday...

Any comments?

--
Dan


More information about the Pm-utils mailing list