lkml.org 
[lkml]   [2004]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Hotplug events for system suspend/resume
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.068 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site