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).
scott
| On St 04-01-06 17:06:09, Alan Stern wrote:
| > On Wed, 4 Jan 2006, Pavel Machek wrote:
| >
| > > > As I mentioned in the thread (currently happening, BTW) on the linux-pm
| > > > list, what you want to do is accept a string that reflects an actual state
| > > > that the device supports. For PCI devices that support low-power states,
| > > > this would be "D1", "D2", "D3", etc. For USB devices, which only support
| > > > an "on" and "suspended" state, the values that this patch parses would
| > > > actually work.
| > >
| > > We want _common_ values, anyway. So, we do not want "D0", "D1", "D2",
| > > "D3hot" in PCI cases. We probably want "on", "D1", "D2", "suspend",
| > > and I'm not sure about those "D1" and "D2" parts. Userspace should not
| > > have to know about details, it will mostly use "on"/"suspend" anyway.
| >
| > 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...
| Pavel
| --
| Thanks, Sharp!
|
| --===============85566774732936779==
| ----------
| _______________________________________________
| linux-pm mailing list
| [email protected]
| https://lists.osdl.org/mailman/listinfo/linux-pm
|
| --===============85566774732936779==--
--
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il 61820
e-mail: [email protected] fax: +1-217-384-8550
phone: +1-217-384-8589 cell: +1-217-433-6114 pager: [email protected]
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
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!
On Thu, 5 Jan 2006, Pavel Machek wrote:
> > > | 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.
Nothing wrong with that. We could let "off" be another synonym. Although
I don't see the need for it, really.
> > 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.
Who are you to say what people really need? What about people who want to
test their PCI device and see if it behaves properly in D1 or D2? How are
they going to do that if you don't let them put it in that state?
What about people with platform-specific non-PCI devices that have a whole
bunch of different internal power states? Why force them to use only two
of those states?
The kernel isn't supposed to prevent people from doing perfectly legal
things. The kernel should provide mechanisms to help people do what they
want.
Besides, as long as the sysfs interface accepts "on" and "suspend" (or
"off"), what harm does it do to accept the device-specific names as
well?
Alan Stern
On Čt 05-01-06 16:37:52, Alan Stern wrote:
> > > 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.
>
> Who are you to say what people really need? What about people who want to
> test their PCI device and see if it behaves properly in D1 or D2? How are
> they going to do that if you don't let them put it in that state?
> What about people with platform-specific non-PCI devices that have a whole
> bunch of different internal power states? Why force them to use only two
> of those states?
Its okay with me to add more states _when they are needed_. Just now,
many drivers do not even handle system suspend/resume correctly.
> The kernel isn't supposed to prevent people from doing perfectly legal
> things. The kernel should provide mechanisms to help people do what they
> want.
We are not adding random crap to kernel just because "someone may need
it". And yes, having aliases counts as "random crap". Perfectly legal
but totally useless things count as a random crap, too.
Bring example hardware that needs more than two states, implement
driver support for that, and then we can talk about adding more than
two states into core code.
Pavel
--
Thanks, Sharp!
On Thu, 5 Jan 2006, Scott E. Preece wrote:
> --===============26103097005026354==
>
>
> 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.
Userspace should do the translation. You should give the user the ability
to specify simple, meaningful states, like "on" and "off". But, it should
be the tools itself that are mapping those requests to valid input for the
sysfs files.
Why force the translation into the kernel, and provide more opportunities
for error in parsing the sysfs files? Do it in userspace, and you can
afford much more flexibility and portability.
Thanks,
Patrick