lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200909030216.04896.rjw@sisk.pl>
Date:	Thu, 3 Sep 2009 02:16:04 +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:46:11, Rafael J. Wysocki wrote:
> > 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.
> 
> Well, I'd prefer to specify -1 as "underflow" and 1000000000 as
> "overflow". Any numbers should work, but ... lets make the interface
> logical if we can.

The interface is already defined, isn't it?  And we're now considering whether
or not to pass the values defined by the interface directly to the user space,
which I think is the right thing to do, because we have no reason _whatsoever_
to change them to anything else.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ