Better integration with power management scripts

[Holger Macht]

On Thu 27. Apr - 11:53:29, Matthew Garrett wrote:
> 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 was just an example where this progress information might be
useful. And you don't know what further methods of suspending the system
might appear in the future. We suffered already from many design mistakes
in the past until we realised that problems arise fast and at a point were
it is to late. There might pop up a situation were this progress
information might be helpful. Just think about any "special" fraction of
people that might have completely different needs (you remember the
embedded people?)  which want do something you/we do not see at the first
place.

And I don't say that it has to be dbus, just an interface were people may
do anything they like at a specific stageprogress of the whole suspend
cycle.

> 
> > 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)

I never said that I need this notifications, but see above.

> 
> > 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?".

I definitely agree with you that the best/correct solution would be to
provide an application the possibility to delay the suspend for this
purpose, but not all applications will be suspend aware, or even better,
aware of any power management, this will simply never happen.

And if pm-utils should only provide mechanism, then it has to be seperated
into many different pieces. If you only trigger suspend via hal and it
runs continuously until its finished, policy making applications don't
have the possibility to make policy decisions. Well, the base that would
be in hal maybe wouldn't need it, but the things vendors/distributions add
might need it. So there must a chance for applications to know at which
stage the suspend cycle is, for example when a vendor script is executed
and when finished.

Providing desktop applications with information what's currently going on
in the mechanism applications is quite useful for them. Because only with
this information they are able to know what to do and how to interact. If
they wouldn't know that, they were just too stupid to make any policy
decisions or to react on unexpected behaviour.

And I know which design mistakes were done inside the powersaved in the
beginning and I don't want these mistales to be redone here. And I
currently see that in some regards, as far as one can say that in this
stage of development, pm-utils might be on the same way to do the same
mistakes again. I simply want to prevent this to happen.

> 
> 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.

Agreed, but you have to give policy applications a possibility to know
what's going on to be able to make policy decisions, see above.


Regards,
	Holger