RE: Let init know user wants to shutdown

[Grover, Andrew]

[do we want to move this to linux-power?]

> From: John Fremlin [mailto:[e-mail]]
> > We are going to need some software that handles button events, as
> > well as thermal events, battery events, polling the battery, AC
> > adapter status changes, sleeping the system, and more.
> 
> Dealing with events should be disjoint from polling the battery or
> powerstatus. Many processes might reasonably simultaneously want to
> provide a display to the user of the current power status.

There should be only one PM policy agent on the system. I don't care about
other processes that query for display purposes, but someone needs to be
alive and checking all the time in order to act on the user's wishes, and
shut down or sleep when the battery hits x minutes remaining, for example.
Let us call this "powerd", for sake of argument.

> However, button presses and so on should be handled by a single
> process. Otherwise the kernel is unreasonably complicated by having to
> deal with multiple processes' veto power, which could just as well and
> more flexibly be handled in userspace.

Exactly, only one entity can be in charge of setting the system's power
policy. So, let's not multiply entities needlessly -- let's make the button
policy manager also be powerd.

> I don't why there needs to be an additional daemon constantly running
> to deal with button presses and power status changes. Apparently init
> is already handling similar things: why should it not be extended to
> include button presses?

Unix philosophy: do one task and do it well. Now that power management is
big enough to be a task in itself (instead of just a minor feature) we
should break it out from unrelated functionality.

> Alternatively, why not forgo a daemon altogether? (This scheme is
> already implemented in the pmpolicy patch, i.e. it is already
> working.)

Because power policy needs to run continuously. Why? Because we need to poll
the battery for battery remaining, and we need to keep a moving average,
because the battery only provides instantaneous power consumption numbers.
Centralizing this means every UI applet can query it, and will show the same
battery remaining value.

Also, because thermal control is not 100% event driven - when we start
passive cooling on the CPU because of a thermal zone overheat, we have to
throttle, and then sample the temperature periodically until the temp goes
below the threshold. (ref: ACPI 2.0 spec chapter 12)

> > We need WAY more flexibility than init provides. 
> 
> Examples please.

See above. I know you may have an affinity for a call_usermodehelper-based
solution, but I hope I have been able to be clear on why I believe an actual
daemon is justified.

Regards -- Andy

PS apm already has apmd (which we would be replacing), so there will be no
net increase in system daemons.