Next gen PM interface

[John Fremlin <chief@bandits.org>]

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