On Čt 05-01-06 11:41:34, Alan Stern wrote:
> 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.
Ok, lets change that to "on" and "off". That way, hopefully all the
drivers will agree that "off" means as low Dstate as possible.
> 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"}.
It is not much more logical. First, noone really needs D1 and
D2. Plus, people want to turn their devices on and off, and don't want
and should not have to care about details like D1.
Pavel
--
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]