[Pm-utils] Re: Better integration with power management scripts

[Holger Macht]

On Thu 27. Apr - 14:35:00, Matthew Garrett wrote:
> On Thu, Apr 27, 2006 at 01:37:30PM +0200, Holger Macht wrote:
> > 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.
> 
> We're designing *now*. We shouldn't be hamstrung by the mistakes of the 
> past. The fact that we have the source code to all the applications we 
> care about means that we /can/ fix the applications that matter - this 
> is what separates us from the Windows world.

And exactly that it the crucial point: "we care about". Who is this "we"?
You? Me? Someone else? And exactly because you don't know who "we" is and
which application he is using, IMO it is most desireable to support as
many applications as possible. Because also users which aren't programmers
and aren't able to fix programs use applications ;-)

> 
> > 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.
> 
> Do you have any use cases where policy decisions need to be made during 
> the suspend process? I honestly can't think of any - all the information 
> is available beforehand.

You need this feedback definitely at least at one point: You need to know
if the suspend succeeded or not.

Imagine a system runs out of battery, the user closes the lid with the
expectation that his laptop goes to sleep. But if there happens something
unexpected, for example there is not enough swap space available or
anything else that causes the suspend to abort in the kernel fails, you
have to inform the policy application about that. You have to inform the
user (maybe playing a sound or similar things) that it needs manual
intervention to prevent a out of battery situation. Or at least give an
application the possibility to shutdown the system short before it really
runs out of battery which might cause filesystem damage.

> 
> > 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.
> 
> Right, but "What's going on during suspend" is (barring bugs) 
> deterministic. You don't need feedback during that process - from a 
> desktop point of view, it should be considered as atomic.

As soons as vendors put their scripts into this architecture, you don't in
which case it might be helpful. But if you don't want to support special
setups, but just the plain basic methods that come along with Hal or the
distributions you think to know of, that's ok. But then I'm sure it's not
the solution that fits most peoples needs.


Regards,
	Holger