Thread (6 messages) 6 messages, 4 authors, 2006-01-05

Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys interface

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2006-01-05 16:41:37
Also in: lkml

On Thu, 5 Jan 2006, Scott E. Preece wrote:
My inclination would be to have the sysfs interface know generic terms,
with the implementation mapping them to device-specific terms. It ought
to be possible to build portable tools that don't have to know about
device-specific states and have the device interfaces (in sysfs) do the
necessary translation.

However, I also think there is value in having the sysfs interface
recognize the device-specific values as well, so that device-specific
tools can also be written (offering the option of taking advantage of
special capabilities of a particular device).
Yes, that was part of my point.
| > It would be good to make the details available so that they are there when
| > needed.  For instance, we might export "D0", "on", "D1", "D2", "D3", and
| > "suspend", treating "on" as a synonym for "D0" and "suspend" as a synonym
| > for "D3".
| 
| Why to make it this complex?
| 
| I do not think there's any confusion possible. "on" always corresponds
| to "D0", and "suspend" is "D3". Anyone who knows what "D2" means,
| should know that, too...
Not necessarily.  For instance, a particular driver might want to map 
"suspend" to D1 instead of to D3.

Given that "on" and "suspend" are generic names and not actual states (at 
least, not for PCI devices and presumably not for others as well), I think 
it makes sense to treat them specially.

And it's not all that complex.  Certainly no more complex than forcing
userspace tools to use {"on", "D1, "D2", "suspend"} instead of the
much-more-logical {"D0", "D1", "D2", "D3"}.

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help