Re: pmf(9) vs sysmon for power events (especially sleep when powerd(8) is not running)

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Thu, May 05, 2011 at 05:56:43PM +0100, Jean-Yves Migeon wrote:
> i am experiencing some difficulties regarding the somewhat duplicity of
> functionality provided by sysmon_*(9) and pmf(9) APIs, for everything that
> has to deal with power management event.

The duplicity is a known and unfortunate issue. Also many drivers suffer
from this. My personal opinion is that we should either rework and cleanup
sysmon's power-related KPI or slowly deprecate it. But, still, pmf(9) can
not do the job alone (at least currently).

> Disclaimer: this is for suspend/save events, whatever you name them; each
> implementation has its own way of specifying them: Xen domU assume that
> sleep/suspension is a serialization of VM memory state to a disk file,
> while ACPI have different expectations depending on level (suspend to RAM,
> suspend to disk, states, etc.)

So you take the stance that there will never be "normal" (APM/ACPI/XXX)
suspend states in Xen? I think Linux supports this already. Thus, generally,
any KPI should handle multiple "backends" with maybe slightly diverging
conceptual definitions.

> Currently, we have two frameworks: pmf(9) and the different sysmon_(9)
> routines.  As I see them, pmf(9) is fairly lower level, and covers only
> device attach/detach/suspension (and inter driver signaling).  sysmon_*(9)
> are "userlevel" oriented, and certain events can even be managed by
> userland through powerd(8) (please confirme about these goals/non goals).

This is quite adequate description. Note that it is still desirable to have
some (but not necessarily all) events delivered to user space. This is the
main task that is currently handled by the sysmon-routines + powerd(8).

> Except for specific situation, "high level events" (LID open/close, power
> button press) are first handled via sysmon, then injected to drivers via
> pmf.

In most cases it is either, not both.

> Would the "sysmon_power" backends be a long term replacement for the
> various shutdown/reboot/sleep/power control (power-on scheduling, sleep
> states) hooks, or should it be just regarded as the registration of a
> sleep handler, and nothing more?

As said, the first approach requires a major cleanup and rationalization of
the "sysmon_power" backend. The second approach may sound reasonable as an
intermediate or a temporary solution for the immediate requirements of 6.0.
That is, I think no one expects you to write a full-blown KPI for this --
a task that is quite non-trivial, as is manifested by the current duplicity.

> I am also having a hard time figuring out the different between the goals
> of sysmon_pswitch_register(9) and pmf_device_register(9).  Both are
> supposed to handle power events, but sysmon_pswitch_register(9) is now a
> NO-OP, with everything directly injected into pmf(9).

The sysmon_pswitch_register(9) is indeed a NOP (it is supposedly there to
account some possible future use). But sysmon_pswitch_event() is not a NOP.
It does not inject anything to pmf(9).

> BTW, would the handler be supposed to be called only when powerd(8) is
> running (with the sleep_button script execing zzz(8)), or could it be used
> when it is not, including situation where there's no real thread context
> (on interrupts)?

Do not confuse the "sleep_button" script with the issue at hand. As the
names indicates, it delivers events from buttons that are physically present
on a computer. I think there should be no requirements for this to work on
interrupt context (if there is, the drivers should do something about it).

- Jukka.