lkml.org 
[lkml]   [2001]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectNext gen PM interface
    From
    Date
    John Fremlin <chief@bandits.org> writes:

    [...]

    > IMHO the pm interface should be split up as following:

    Nobody has disagreed: therefore this separation must be perfect ;-)

    > (1) Battery status, power status, UPS status polling. It
    > should be possible for lots of processes to do this
    > simultaneously. [That does not prohibit a single process
    > querying the kernel and all the others querying it.]

    Solution. Have a bunch of procfs or dev nodes each giving info on a
    particular power source, like now, but vaguely standardise the output.

    > (2) Funky events happening to the physical machine, like a
    > button being pressed, the case being closed, etc. [Should this
    > include battery low warnings, power status changes? I don't
    > know.]

    Solution. Have a special procfs or dev node that any number of people
    can select(2) or read(2). Protocol text. Syntax:

    <event> <WS> <subsystem> <WS> <description> <LF>

    Where <event> is one of the strings
    OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, <WS> is a space character,
    <subsystem> is a word signifying the kernel pm interface responsible
    for generating th event, <description> is an arbitrary string. <LF> is
    a newline character \n.

    This is flexible and simple. It means a reasonable default behaviour
    can be suggested by the kernel (OFF,SLEEP,etc.) for events that
    userspace doesn't know about and yet userspace can choose fine grained
    policy and provide helpful error messages based on the exact event by
    checking the description.

    [...]

    > (3) Sending the machine to sleep, turning it off. It should be
    > possible to do this from userspace ;-)

    I would suggest that all pm capable objects should be able to be
    controlled individually. E.g. you should be able to send your monitor
    to sleep alone, leaving other stuff running. Fbdrivers are already
    capable of this on some archs.

    IOW I suggest a nice FS with a dir per PM capable device. In this
    dir would be

    name - descriptive text name of device class

    wake - writing to this node wakes device

    sleep - writing a number n (text encoded) sends the device to
    sleep in such a way that it can be back in action in no less
    than n seconds after a wakeup call on a vague guess
    basis. Reading from it gets errno.

    off - writing to this node puts device in deepest possible
    sleep, possibly losing state. Reading gets errno.

    Like the proc/sys/net/ipv4/neigh stuff you can have an all/ dir that'd
    try to whatever to everything. Hotunplug can be handled.

    Any objections? Would such a patch be accepted by the powers that be?

    [...]

    --

    http://www.penguinpowered.com/~vii
    -
    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 13:26    [W:0.023 / U:121.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site