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