linux-kernel - Re: [RFC] Staging:IIO: New ABI

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:	Tue, 26 Jan 2010 11:33:49 +0100
From:	Manuel Stahl <manuel.stahl@....fraunhofer.de>
To:	"Hennerich, Michael" <Michael.Hennerich@...log.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Greg KH <greg@...ah.com>,
	Jonathan Cameron <kernel@...23.retrosnub.co.uk>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	"Frysinger, Michael" <Michael.Frysinger@...log.com>,
	"Getz, Robin" <Robin.Getz@...log.com>,
	Jean Delvare <khali@...ux-fr.org>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	Ira Snyder <iws@...o.caltech.edu>
Subject: Re: [RFC] Staging:IIO: New ABI

Am 26.01.2010 11:25, schrieb Hennerich, Michael:
>> From: Dmitry Torokhov [mailto:dmitry.torokhov@...il.com]
>> On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote:
>>>
>>>
>>>> From: Dmitry Torokhov [mailto:dmitry.torokhov@...il.com]
>>>>
>>>> On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote:
>>>>> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote:
>>>>>> On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote:
>>>>>>> On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron
> wrote:
>>>>>>>> I am not aware of these. Could you direct me to the current
> api? Also note that these
>>>>>>>> aren't the actual alarms, merely a means of enabling the
> relevant event on the related
>>>>>>>> event character device.
>>>>>>>
>>>>>>> Hm, I thought we had an accelerator interface somewhere...
>>>>>>>
>>>>>>
>>>>>> Nope. And I am also interested in this since I am sittign on a
> bunch of
>>>>>> accelerometers, magnetometers, etc drivers that are trying to
> plug into
>>>>>> input sysbsystem and quite unsure what to do with them.
>>>>>>
>>>>>> It was OK whch HDAPS and friends when they were using input for
>>>>>> secondary, toyish purposes, but these new drivers trying to use
> input
>>>>>> devnts as primary API and I am unsure if it is the best
> solution.
>>>>>> Accelerometer might be used as an input device but not always an
> input
>>>>>> device.
>>>>>
>>>>> Yeah, I see it using a joystick interface, which might be
> acceptable for
>>>>> "toy" devices like you say.
>>>>>
>>>>> But for "real" ones, we should do something else.
>>>>>
>>>>> Maybe, for devices that are going to be used by x.org, like the
> "toy"
>>>>> ones, we stick with the current input interface, but for others,
> we use
>>>>> a "real" interface, probably through hwmon, so that users can get
> the
>>>>> real data out in a consistant manner.
>>>>>
>>>>
>>>> I'd rather have all of them use real interface and then have a
> bridge
>>>> to input module to enable toyish mode (unless the device in question
>>>> is really truly an input device).
>>>>
>>>> --
>>>> Dmitry
>>>
>>
>>> I really don't see that hwmon provides facilities like input/evdev
>>> does.  Queuing of events with time stamping and multiple reader
>>> support.
>>
>> I understand that using evdev might be very convenient but I still
>> believe that input should be used for human interfaces, not for generic
>> data acquisition. The idea is that userpsace consumers should be able
> to
>> query device's capabilities and based on those capabilities be able to
>> classify and properly handle the device. Now it all breaks when we get
>> random hardware using EV_ABS/ABS_* for delivering some datastream that
>> has nothing to do with coordinates.
>
> Acceleration in X,Y,Z translates pretty well in what joysticks deliver.

But it's not only about accelerometers here. We also have gyros, 
magnetometers, pressure sensors and generic ADCs.

>>>   The adxl34x accelerometer driver for example is really
>>> intended to be a input device.  Send EV_KEY for x,y,z_TAP detections,
>>> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration.
>>> With very minor platform data customization you can use this device
>>> for game controls or GUI interaction.  A few examples include digital
>>> picture frames, ebook readers, etc.
>>>
>>
>> I see. However, can it be reasonably used for other purposes?
>
> Well - it depends. Some applications for Accelerometers also include:

> Personal navigation devices
(low to mid data rate)

> Hard disk drive (HDD) protection
(only alerts)

> Safety
(probably low data rate)

What we want with IIO is a common high performance interface to these 
devices. That's why we have ring buffers in the kernel. Possible 
applications are robotics, precise navigation, data aquisition, etc.

Regards,
-- 
Dipl.-Inf. Manuel Stahl
Fraunhofer-Institut für Integrierte Schaltungen IIS
- Leistungsoptimierte Systeme -
Nordostpark 93                Telefon  +49 (0)911/58061-6419
90411 Nürnberg                Fax      +49 (0)911/58061-6398
http://www.iis.fraunhofer.de  manuel.stahl@....fraunhofer.de

View attachment "manuel_stahl.vcf" of type "text/x-vcard" (162 bytes)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (6148 bytes)