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 13:32:36 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Ben Dooks <ben-linux@...ff.org>
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>, 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)

Ben Dooks wrote:
> On Wed, Jul 23, 2008 at 06:00:29PM +0100, Jonathan Cameron wrote:
>> Dear All,
>>
>> The need for an industrialio subsystem was discussed in
>> http://lkml.org/lkml/2008/5/20/135
> 
> The name is really bad, this sounds like something for doing large
> scale industrial process control.
To a certain extent I agree, it's a pretty hideous name and I'm happy to change
it if someone can come up with a better one whilst maintaining the flexibility
to handle devices that do a range of different sensing and output tasks.
 
>> Firstly thanks to all the people who have contributed to the discussion
>> of this in the past.
>>
>> In brief the intention is provide a kernel subsystem directed towards the
>> handling on sensors (and later related output devices) such as ADC's,
>> accelerometers and many others.
> 
> We've already got an perfectly good hwmon framework, do we really need
> to do this again?
On this, see the original discussion (where using that was one of the options)
discussed.  Basically it comes down to a different set of requirements with
the ability to handle events from the device, ring buffering and higher (non
cached) update rates.  Whilst we could have bludgeoned the functionality into
that framework, it was decided that it was better to start afresh. 

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/