Messages in this thread |  | | | Subject | Re: Next gen PM interface | | From | John Fremlin <> | | Date | 19 Apr 2001 20:07:43 +0100 |
| |
Patrick Mochel <mochel@transmeta.com> writes:
[...]
> > 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. > > First, Is there any reason why the kernel should do more text processing?
Kernel does no text processing. Kernel merely gives text instead of magic numbers to the stream of bytes.
> It is better left for user space. Besides, enumerated values > translated by userspace seems more efficient than copying and > parsing strings.
Oh? Do you honestly believe there will be in any way a detectable difference? > Having a daemon that sits in user space and waits for system events > (denoted by enumerated values in some /proc or /dev file) seems simple > enough.
Yes, but text strings are simpler. You don't have to export magic numbers in some kernel header (causing no end of woe). You can just cat /proc/pm/events to the console and understand it, and just about anybody with the rudiments of knowledge about programming in any language can write an event handler - even without having to know hardly anything about or look at the kernel source because the interface is so transparent and simple.
> When it gets the request to power down, it handles calling init and > whatever else it wants to do. When it gets notification that the > laptop was plugged into the base station, it can look for new > devices and load the modules for them.
Exactly. Right. Bang on target - but with text strings you can do it in a line or two of perl, and the kernel side is not made any more complex.
> This can also handle the user-dictated policy, which I haven't seen > discussed yet. For instance, when you close the lid or press the power > button, the system can enter suspend or it can power off. If the kernel > simply exported the event, the userspace daemon could simply check its > config file for the proper thing to do and initiate the transition.
Exactly what I was suggesting. In this case, you'd get the event
SLEEP ACPI Laptop case closed
and your perl script could do something vaguely like
/ACPI Laptop case closed$/ && system "shutdown -p now";
to turn the machine off instead of sleeping.
[...]
> > 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.
Probably microseconds would be a more useful unit.
> > off - writing to this node puts device in deepest possible > > sleep, possibly losing state. Reading gets errno. > > Sure, but does it really make sense for anything but system sleep > states? ACPI defines a mechnanism for runtime power management, > where devices will go into sleep states if they're not being > used. Given proper heuristics for controlling this, user-initiated > suspension of individual devices doesn't seem necessary. And, given > a proper abstraction in the PM layer, this should be extendable, to > some extent, to other low-level PM schemes.
OK, so add another node, something like
boredafter - writing a number of milliseconds tells device to go to some sort of sleep after that time has elapsed without activity.
--
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/
|  |