[lkml]   [2001]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectNext gen PM interface
John Fremlin <> 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
<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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.182 / U:0.320 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site