linux-kernel - Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc within the kernel.

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: <20080527140348.ZZRA012@mailhub.coreip.homeip.net>
Date:	Tue, 27 May 2008 15:01:07 -0400
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Ben Dooks <ben@...ff.org>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	spi-devel-general@...ts.sourceforge.net,
	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	linux-kernel@...r.kernel.org,
	LM Sensors <lm-sensors@...sensors.org>
Subject: Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc within
	the kernel.

Hi Ben,

On Tue, May 27, 2008 at 06:16:56PM +0100, Ben Dooks wrote:
> > 
> > I don't think that input subsystem woudl be the best choice. While we
> > do support the event-driven mechanism for delivering information to
> > userspace input is mostly oriented for human interface devices, not
> > general data acquisition. If anything input_dev is too fat. Another
> > thing is that input layer anonymizes input devices, makes them
> > capability-oriented. I.e. we dont really care what model of joystick
> > we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and
> > userpsace can use it whether it a simple analog joystick or something
> > fancy and USB connected. For your purposes you probably do want to know
> > what the device is and what exactly being sampled/measured.
> 
> Can you explain to me how the input system anonymizes things? I thought
> it was quite easy to read the name of the device? You could easily add
> a symlink from the driver's device binding in sysfs to the relevant
> input device as well.
> 

Yes, it is possible to read the name of the device, but I could see
with names like "Thermal probe blah" it may not be unique enough. Of
course input core also exports phys, sysfs and uniq attributes so
there are certainly possibilities for using it.

OTOH input_dev is quite fat and oriented for human interface. It could
made work if you create one device per sensor but devices with X
sensorts per one device (that provide related readings, like a generic
state) would be cludgy... Accelerometers could use ABS_X, ABS_Y.. but
what about other devices? ABS_RAW1, ABS_RAW2? And here we run into the
conceptual problem, as I see it - in input we try to keep meaning of
the event independent from the device it generated. We dont care what
generated ABS_X, ABS_Y, BTN_FIRE - it could be a joystick, gamepad,
something similar. A program can use it if it knows how handle the
above events.  The ABS_RAWx would mean different things for every
sensor... That's what I meant by anonymizing - the application
does not really care about the particular device and where and how it
is connected, but only about its capabilities.

Another thing is that (at least now) input supresses duplicate events,
which may be undesirable for generic data acquisition device.

I suppose it could be made work. I guess the size of input_dev is my
main concern. If you hyave something with hundreds of sensors
input_dev might be too expensive.

> Also, why would you not want all your accelerometers grouped into a set
> of accelerometers? If your application software just searches all input
> devices for anything reporting itself as an accelerometer, then it would
> get the right result... 

I never said I would not want them to be grouped together.

-- 
Dmitry
--
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/