I think Pavel's points are important. Unless we're prepared to expose exactly the ACPI semantics (and I don't think we are), we need to make sure that the namespace is not easily confused with ACPI's namespace. I would also prefer names to numbers, for the reasons already pointed out - harder to confuse, less likely to be taken as an arithmetically-interpretable ordered sequence, and easier to insert new values into actual ordered sequences. However, I also have to admit that I like the notion of the zero-state meaning having a consistent meaning across the different atttributes and it might be good to have a similarly consistent name for the maximum/full-operation state across the attributes... scott -----Original Message----- From: linux-pm-bounces@xxxxxxxxxxxxxx [mailto:linux-pm-bounces@xxxxxxxxxxxxxx] On Behalf Of Pavel Machek Sent: Thursday, April 20, 2006 8:26 AM To: Brown, Len Cc: David Brownell; linux-pm@xxxxxxxxxxxxxx Subject: Re: [linux-pm] RE: on-ness 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!
