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:3.358 / U:1.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site