On Wednesday 02 September 2009, Pavel Machek wrote: > On Wed 2009-09-02 23:12:58, Rafael J. Wysocki wrote: > > On Tuesday 01 September 2009, Pavel Machek wrote: > > > > > > > > > IMO, 0 and -1 are not errors. they just suggest that the Ambient Light > > > > > > illuminance is beyond the device support range, while the device is > > > > > > still working normally. > > > > > > what about exporting these values (0 and -1) to user space directly? > > > > > > > > > > Returning 0 for "below" range and 99999999 for "above" range would be > > > > > nice, yes. > > > > > > > > Why not 0 and "all ones" or 0 and -1. > > > > > > > > Is there anything wrong with -1 in particular? > > > > > > Normal people expect -1 to be less than 123, and output is in ascii. If > > > you make it ((unsigned) ~0) I guess that becomes acceptable. > > > > Well, "-1" is a perfectly valid alphanumerical representation of an int. > > I don't really see the problem with the "-", unless we're talking about some > > broken user space, that is. > > No. But if you see illumination value of -1 lumen, do you really > expect a *lot* of light? Not really. I'd rather intrepret it as "the number is not to be trusted", which is what it means. The problem with "all ones" is that it depends on the size of the underlying data type, which is not nice. Also, if you want that to be a "big number", there's no clear rule to tell what the number should actually be. Anyway, this really is a matter of definition. If we document the attribute to read as "-1" in specific circumstances, the user space will have to take that into account. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
