On Fri, 6 May 2011 13:05:35 +0300, Jukka Ruohonen wrote:
Speaking about normal x86 and other architectures, we should pick good defaults but not tie things to the kernel. Formulating one-and-true policy or "power-event state machine" is not a goal that can be even reached. I want my laptop to suspend when the lid is closed, but someone else may not like. It is more than natural that things like this are handled in user space. Like is done currently with powerd(8), it is also a good idea to shutdownother daemons before entering a suspended state.
In some cases, this can lead to frustration. For Xen domUs, one would schedule a save in dom0. If powerd(8) is not running, crashed, is non responsive, etc. you end up with a xm/xl command that will never return. You must then connect to domU (assuming you know what the culprit is), run the sleep_button script by hand (powerd(8) being absent, the event is lost), and wait. Or do the sysctl machdep.sleep_state/zzz yourself.
I still believe that a minimal sane default should apply in kernel, in cases where powerd(8) cannot handle the event. This has to be defined on a per-backend basis, of course. Hence, my questions, as I am not really sure whether: 1 - I shall patch sysmon_pswitch_event and add a callback for sleep that MD code can register, 2 - or register a pmf(9) event handler during hypervisor attachment, and just use pmf_event_inject() in the /* XXX */ sleep path that will trigger this handler.
Ah, right. Of course you should follow what those injections actually
do
and where the listeners are? The main function in sysmon_power.c is:
936 if (sysmon_power_daemon != NULL) {
937 /*
938 * Create a new dictionary for the event.
939 */
940 ped = kmem_zalloc(sizeof(*ped), KM_NOSLEEP);
941 if (!ped)
942 return;
943 ped->dict = prop_dictionary_create();
944
945 if (sysmon_power_daemon_task(ped, smpsw, event) ==
0)
946 return;
947 }
[1] In lack of a better reference see e.g.
http://lists.xensource.com/archives/html/xen-devel/2010-05/msg00115.html
This one applies to dom0 suspension, and is functionally very close to a typical kernel ACPI sleep (except that power management is shared between dom0 and Xen, and both have to cooperate for it to work nicely).
My mail relates strictly to domU suspension. dom0's one requires ACPI support in dom0 first, and that alone is a separate work.
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost