[Pm-utils] [PATCH 1/6] Split hook running into two phases -- core and aux

[Stefan Seyfried]

Victor Lowther wrote:
> On Fri, 2008-05-16 at 10:47 -0700, Dan Nicholson wrote:
>> Hi Victor,
>>
>> On Sun, May 11, 2008 at 6:43 PM, Victor Lowther
>> <victor.lowther at gmail.com> wrote:
>>> Core phase is for hooks that work around software or hardware quirks
>>> that may cause the system to not suspend correctly. Hooks will automatically
>>> fall into this category if their filenames start with at least two digits.
>>>
>>> Aux phase is for programs that want to do something when the system suspends
>>> or resumes, but that do not need to run in any particular order or whose
>>> success or failure has no bearing on whether or not the suspend/resume
>>> process should fail.
>> I would really prefer that we just tighten the specs on hooks instead
>> of getting creative with what hooks run when and whose errors are
>> critical. In my mind, the hooks should work like this:
>>
>> 1. Hooks are run in lexicographical order on suspend and reversed on
>> resume. If your hook depends on running early or late, name it so that
>> it sits at an appropriate place in the order. Maybe a restriction that
>> it must begin with two digits, in which case, 50$hookname if you don't
>> care when it runs.
> 
> Fair enough, although we should define some critical points in the
> sequence (e.g. after ?? don't rely on modules being loaded, etc), and
> mabye shuffle the hook ordering around a bit (for example, the ordering
> of 50modules to 65alsa is obviously wrong).
> 
> As a starting point, how about the following convention:
> 
> 00 - 49: user and (most) package supplied hooks that can assume that all
> of the usual services and userspace infrastructure is still running.
> 
> 50 - 74: service-handling hooks (mainly stopping and starting services,
> saving any state they may need, etc)
> 
> 75 - 89: module and non-core hardware handling (usb, audio, network,
> etc).
> 
> 90 - 99: reserved for critical pre-suspend hooks, starting with 90chvt
> and 90modules and ending with 99video
> 
> At or before 50, you can assume that all services are still enabled.
> 
> At or before 75, you can assume that all modules are still loaded.

I'd say this is seriously overengineered.
Hooks that depend on having certain modules unloaded should just unload them
by themselves.
The SUSPEND_MODULES hack is only to let users add broken modules. In general,
distributions should always ship with an empty SUSPEND_MODULES and just fix
their kernel.

Remember: almost all of those hooks are only workarounds for breakage that
needs to be properly fixed anyway. So with that convention you are only
encouraging people to write sophisticated hooks instead of fixing the real
issue. This is fundamentally wrong and contradicts the original goal of the
project IMVHO.

Even though it was written with networking in mind, i found that rfc1925
pretty much describes all the problems with this approach ;)
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)