Re: RE: on-ness

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Hi!

> (restored linux-pm to cc:)

> no, if the numbers happen to corrolate to ACPI states,
> that is purely lucky for the ACPI maintainer:-)
> But honestly, we should "leverage" all we can from ACPI.
> My role, of course, it to make sure that the generic
> description can accommodate everything ACPI can do.

Please, put there translation layer from the begining. Otherwise
people will assme they *are* ACPI states, and great confusion will
begin.

See suspend functions, where half people assumed they are acpi Dx
states, half people thought they are pci Dx states, and half the
people assumed they are system Sx states.


It took quite long to sort out.

> yes, idle refers to either Cx or Dx states -- it depends
> on the device.  0 means operating, non zero means non-operating.
> 
> Re: strings.
> we breifly debated strings vs numbers.
> I'm not confident that there are enough unique strings
> available without falling into state0, state1, state2, state3 --
> so numbers seemed simpler.
> The only issue I see with numbers is that they imply order,
> and it may be that some operating points might not have
> such a strict order.

Second issue is that you might want to "insert" between states.

Lets look at disk. Old disks had:

spinning
spindown

states. You'd name them 0 and 1, eventually apps will learn to use
that. But (some) newer disks have

spinning
slowspin
spindown

if app does echo 1 > state, it will get slowspin instead of spindown
it wanted.

Yes, inventing good names may be tricky in some cases, but in other
cases names are very natural (arm has sleep, deep sleep and big sleep,
iirc).... And we can always fall back to state0..state5.

						Pavel
-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]