linux-kernel - Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)

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:	Thu, 24 Jul 2008 14:37:23 +0200
From:	Eric Piel <eric.piel@...mplin-utc.net>
To:	Jonathan Cameron <jic23@....ac.uk>
CC:	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	mgross@...ux.intel.com, Dmitry Torokhov <dtor@...l.ru>,
	LKML <linux-kernel@...r.kernel.org>,
	LM Sensors <lm-sensors@...sensors.org>,
	David Brownell <david-b@...bell.net>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Jean Delvare <khali@...ux-fr.org>,
	spi-devel-general@...ts.sourceforge.net,
	Ben Nizette <bn@...sdigital.com>
Subject: Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs,
 accelerometers etc)

Jonathan Cameron schreef:
:
>> * If the accelerometer is soldered on the computer, define once for all 
>> to which _physical_ movement corresponds which axis (eg: a laptop on its 
>> normal position going up has axis Z increasing).
> Agreed, though this is more documentation (and strict enforcement on drivers)
Indeed, it's more about defining conventions. A one page document saying 
to userspace developers how they can expect any accelerometer driver 
will behave is desperately needed. The more conventions, the more all 
the drivers will behave similarly, and the easier it will be for 
userspace programs to be written :-)

>> * Free fall event. Either it's hardware detected, or the accelerometer 
>> infrastructure will detect it in software.
> Hadn't thought of doing that in software - should be relatively straight
> forward, though would involve a fairly large overhead if the intention
> is to detect it fast enough to park hardware etc. (similar to that for
> the ring buffer I guess).  I'll look into getting that done for the next
> version (maybe driver specific for now).
Yes, on a second though, this is a low priority point. If userspace is 
able to know if the hardware has or not freefall detection, it should be 
possible to just implement the software detection in the userspace 
daemon. People might come up with lots of "clever" algorithms for that, 
so it might be better to not do too much in the kernel ;-)


> 
> At the moment the big missing element of the subsystem is an easy way of
> querying what is there. (proc interface similar to that for the input subsystem)
You mean /sys/class/input/, right? Indeed, something inspired by the 
input subsystem should work well.

See you,
Eric
--
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/