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

[Victor Lowther]

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.

If we want to try and enforce this convention, we will want to ignore
all hooks whose names do not begin with a numeric prefix.  This is also
easuly codeable.


> 2. Failures from hooks always result in suspend or resume errors. If
> the hook has non-critical errors, then it should return 0, full stop.
> If someone doesn't have bluetooth or NetworkManager or ntpd isn't
> running, that should not be considered a critical error. I don't
> consider alsactl failing to be worth more than a warning in the logs,
> but I think the better way to handle this is the hook not returning a
> failure, not marking the hook as some sort of special case.

I am fine with this -- hooks can (and do) signal when they are not
applicable using the $NA return code.

> That's how I see it, anyway. I think we can just make the current
> hooks more robust rather than re-implement the hooks structure. If
> there are hooks we're distributing that are difficult to get right,
> then let's not install them by default. Distros can add or remove the
> hooks as apply to their system.

Hmmm... my proposed patch series does not re-implement hook handling, it
merely extends it -- right now in this patch series abort-on-error is
not implemented, and if you do not remove numeric prefixes from the
hooks they will run in exactly the same order they used to.  The only
difference is that hooks without a numeric prefix will run in parallel
with eachother, and we will not run the core hooks until the aux hooks
finish (and as a bonus, the system will be up and usable without needing
to wait for the aux hooks to finish).

> --
> Dan
-- 
Victor Lowther
Ubuntu Certified Professional