[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200909022346.11475.rjw@sisk.pl>
Date: Wed, 2 Sep 2009 23:46:11 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Pavel Machek <pavel@....cz>
Cc: Zhang Rui <rui.zhang@...el.com>, Len Brown <lenb@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-acpi" <linux-acpi@...r.kernel.org>, Greg KH <greg@...ah.com>
Subject: Re: [PATCH V6 1/2] introduce ALS sysfs class
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists