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

[Alan Stern]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/