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 > <[EMAIL PROTECTED]> 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 _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
