Re: Hotplug events for system suspend/resume

[Todd Poynor <tpoynor@mvista.com>]

Nigel Cunningham wrote:

> You're thinking ACPI drivers initiating a suspend? They would do it through 
> acpid, wouldn't they? At least that's the glue I use to get my sleep button 
> to initiate a suspend. I would assume thermal events would/should work the 
> same.

Hi, my main interest is embedded platforms that may or (usually) do not 
implement ACPI.  Therefore, part of what I've been generally driving at 
is that there may be value to adding support for these sorts of 
kernel-to-userspace notifiers in the generic power layer.  As I 
understand it (and I might be behind the times here, please do correct 
me if I'm wrong), acpid reads ACPI-specific power event notifiers, such 
as button pressed, thermal limit exceeded, etc. from the kernel via 
/proc, and acpid executes scripts in /etc/acpi/ to handle the event. 
Some of the embedded developers I deal with have asked for similar 
notifiers in a non-ACPI context.  The system suspend/resume notifiers 
discussed in this thread could be thought of as a general form of "sleep 
button pressed" type event.  (And I now realize it may have been better 
to implement and pitch it as such.)

So, independently of the merits of any particular event notification, it 
may be worth discussing whether there's advantages to using the hotplug 
mechanism for userspace notification and script execution for power 
events, and hooked into the generic power subsystem.  The likely 
alternative is that acpid continues doing things its way and non-ACPI 
systems do something rather different (we already have acpid-like event 
notifiers via sysfs attributes and I'm trying to get rid of them).  Not 
that this ranks among the most pressing of issues facing Linux today, 
but since a generic power subsystem has been created, and since it takes 
some steps toward abstracting away various ACPI specifics, I think 
there's arguably some benefit to taking this particular step as well. 
An acpid-like interface (or even directly adapting acpid) for non-ACPI 
systems is another possibility.

I'd be happy to discuss this further if there's interest.  Thanks -- Todd


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel