From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [Industrial I/O] [0/13] RFC: IIO v3 patchset Date: Mon, 1 Dec 2008 19:41:36 +0000 Message-ID: <20081201194136.039e201b@lxorguk.ukuu.org.uk> References: <4933F291.4020001@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Dmitry Torokhov , LM, LKML , Sensors , David Brownell , Jonathan Cameron , Jean Delvare , spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Ben Nizette To: Jonathan Cameron Return-path: In-Reply-To: <4933F291.4020001-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org > have both functions. The sort of devices we are talking typically > communicate over I2C or SPI buses though drivers for rs232 devices etc are > definitely on the cards. Basically we are interested in devices where direct > memory mapped access is not possible. We have I2C and SPI drivers so I assume you will use the lower layers of the stacks to do this ? > For discussion of why these don't fit within existing subsystems see > http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. I don't see much there which says why you can't unify all this in a user space library. For RS232/423/.. devices you can go this path if you want (but I would keep it all in userspace anyway) as you can use a line discipline to sit on top of the port and provide another interface (eg the way PPP does) ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/