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

[Victor Lowther]

On Fri, 2008-05-16 at 16:57 -0700, Dan Nicholson wrote:
> On Fri, May 16, 2008 at 4:10 PM, Victor Lowther
> <victor.lowther at gmail.com> 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:
> > 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 think that convention is reasonable. Udev is a far more complicated
> system than pm-utils, and it's gotten away fine without enforcing any
> serious restrictions on the rules files. If a rule file is in the
> wrong location, well, then move it to a better one. But I think the
> above specification is good.

I will go ahead and code this bit up, and if it ends up being the only
thing out of all these threads that I put into master I will call it a
win. :)

> > 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.
> 
> Enforcement is probably good, and a warning would probably be good,
> too. Silently ignoring a hook that used to run would be lame.

Yeah, I will continue to log all hooks that did not run with the reason
why.

> > 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).
> 
> You're right, it's extended, not re-implemented. I just don't see
> enough justification for it. The tradeoff in complexity and confusion
> isn't enough for the gain in functionality, IMO. Cause really, the
> pm-utils hooks are just a handful of commands to run besides the
> actually important part of suspending and resuming. For nearly all
> users, running the commands in a serialized order is perfectly
> adequate. But if you want to extend the hooks in a regression-free,
> backwards-compatible way, drive on.

:)

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