Better integration with power management scripts

Matthew Garrett mjg59 at srcf.ucam.org
Thu Apr 27 03:53:29 PDT 2006


On Thu, Apr 27, 2006 at 08:54:08AM +0200, Holger Macht wrote:

> Well, the things we do need about 2 seconds, but I said already that this
> is just a "nice to have" feature. What bothers me more is how you would do
> a graphical bootsplash or the like for suspend2 without any progress
> information. So what about seperating the suspend/resume into different
> stages or doing something similar like the above:

The part of hibernation that takes any significant period of time at all 
takes place while userspace is frozen. There are ways of providing 
graphical feedback, but you *really* don't want to be relying on dbus at 
that stage - the more code that's left running while memory is being 
copied to disk, the greater the chance of it all exploding in a violent 
and data-corrupting sort of way. 

> It is simply to add this function call in different places or again,
> provide the infrastructure for others adding it.

If the suspend process takes long enough that people need notification, 
then we've already lost. I'd prefer to design something that makes the 
assumption we can reach the correct solution, rather than designing 
something that encourages people to think that the wrong solution is 
good enough (see also removing modules before suspend - I've already 
learned from that one)

> We also don't have that for some time now but experienced that there are
> situations were need the knowledge of the helper scripts to ask valuable
> questions. And it would make things easier for vendors to do clever things
> if we provide them with the proper infrastructure.

Asking questions is a policy determination. pm-utils should be providing 
mechanism, not policy. The right place to be asking questions is 
powersaved or gnome-power-manager - places that already have some idea 
what's going on with the rest of the system. For your CD burning 
example, the correct way of doing things is for a policy daemon to say 
"I'm going to suspend now", and the CD burning application to say 
"Please don't, I'm doing something important". It's /not/ for the 
suspend process to say "This looks like a CD burning application. I've 
no idea what it's doing, but are you sure you want to suspend?".

Please, let's make a distinction between mechanism and policy. Policy 
("Do you want to suspend?", "Critical battery level reached, I'm 
hibernating now", "Suspend inhibited by cdrecord application" and so on) 
should live in one place, and mechanism (suspending devices, putting the 
machine to sleep) should live in another. Right now, hal provides 
mechanism and powersaved and gnome-power-manager provide policy. Keeping 
the line distinct makes it easy to implement new policy on top of 
existing mechanism. Putting policy in hal would be an error, and putting 
mechanism in the policy daemon would make life generally more 
complicated.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the hal mailing list