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]

Message-ID: <48887377.2030905@cam.ac.uk>
Date:	Thu, 24 Jul 2008 13:20:07 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Ben Dooks <ben-linux@...ff.org>
CC:	Eric Piel <eric.piel@...mplin-utc.net>, 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>,
	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	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)

Dear Ben,
>> In particular, what I think would be worthy would be:
>> * Up to 3 pre-defined axes (X, Y, Z) - that's provided by your current  
>> version of industrialio
>> * 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).
>> * Free fall event. Either it's hardware detected, or the accelerometer  
>> infrastructure will detect it in software.
>> * For each axis, what is the maximum and minimum bound and the unit -  
>> Probably worthy for the whole ADC infrastructure
>> * Joystick emulation (calibrated so that when the computer is not  
>> moving, all the values are at 0). All the current drivers have it.
> 
> I think if we're trying to make something that will cover a number
> of device classes, we need to be more like HID and have a system
> that reports and possibly records the following:
Ok, this is the key disagreement at the moment on the approach to be
taken here.  I'd again argue that the purpose of events in this subsys
are very different from what you describing.  Events tend to indicate
that something has happened (eg. the Free fall even mentioned above),
not that the current value of something is x.  It may be that we
will have devices that do indeed act closer to you conventional
user interface device and provide (x moved to 103 etc).  If we
do then this may all need rethinking.
 
> 1) What data is possible to be returned from each event, with the
>    units, magnitude and any scale applied by the device sending.
> 
> 2) Each event should be able to report a number of items, so that
>    if the sensor reports X/Y/Z in one go, there is just a single
>    event containing those values.
Agreed.
 
> 3) A well defined set of information that can be read (like #1)
>    that can provide details of the device and how it relates to
>    the environment it is in.
Indeed, this is crucial and probably forms the next element of the
code to be written.  At the moment I'm inclined to go with an approach
similar to the input subsystem with it's proc interface that provides
a nice machine readable description of device functionality.

Anyone have any other suggestions on how this can be sensibly achieved?

Thanks,
--
Jonathan Cameron
--
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/