linux-kernel - Re: [PATCH v2 3/5] toshiba_acpi: Fix accelerometer direction reporting

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Sep 2014 12:56:17 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Azael Avalos <coproscefalo@...il.com>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v2 3/5] toshiba_acpi: Fix accelerometer direction
 reporting

On Mon, Sep 15, 2014 at 12:29:27PM -0700, Darren Hart wrote:
> On Fri, Sep 12, 2014 at 06:50:37PM -0600, Azael Avalos wrote:
> > The position file on sysfs was reporting absolute values
> > for its axes.
> > 
> > This patch fixes the direction reporting (either negative
> > or positive), as well as added a mutex lock to it.
> > 
> 
> Hi All,
> 
> I've added Greg KH, Rafael, and H. Peter Anvin to get some clarity on a topic
> which is coming up repeatedly in the platform-drivers-x86 subsystem.
> Specifically, whether or not the driver-specific sysfs attributes should be
> considered a "stable userspace interface".
> 
> The sysfs documentation [1] specfifically calls out the following types of
> device properties:
> 
> o devpath
> o kernel name
> o subsystem
> o driver
> o attributes (the topic of this email)
> 
> In the case of this patch, Azael proposes changing the x,y,z attributes from the
> absolute values read from the device to relative signed values.
> 
> In my opinion, this changes a userspace interface that exists prior to this
> development cycle. As such, the attributes must remain as they are and new
> attributes should be added if a new interface is wanted/needed. New x_rel,
> y_rel, z_rel attributes could be added for this purpose.

Yes, never change existing files to start showing different types of
values, that's not ok.

But you can remove an existing file and replace it with something with a
different name, _IF_ the userspace tool that was using it can also be
changed.  But don't go creating new interfaces when an existing one is
already present, as shown by:

> I have also suggested this device (2 actually) would be better supported as an
> IIO accelerometer device, but even that would change the sysfs interface by
> removing these altogether and using the IIO standardized path and accelerometer
> interface.

That's a better goal overall, then the "odd" sysfs files are now gone,
to be replaced with the standard interface which all tools should
already be using.

hope this helps,

greg k-h
--
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/