Message-ID: <20060830175529.GB6258@kroah.com>
Date:	Wed, 30 Aug 2006 10:55:29 -0700
From:	Greg KH <greg@...ah.com>
To:	Matt Porter <mporter@...eddedalley.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] Simple userspace interface for PCI drivers

On Wed, Aug 30, 2006 at 09:34:10AM -0500, Matt Porter wrote:
> On Tue, Aug 29, 2006 at 11:23:38PM -0700, Greg KH wrote:
> > A while ago, Thomas and I were sitting in the back of a conference
> > presentation where the presenter was trying to describe what they did in
> > order to add the ability to write a userspace PCI driver.  As was usual
> > in a presentation like this, the presenter totaly ignored the real-world
> > needs for such a framework, and only got it up and working on a single
> > type of embedded system.  But the charts and graphs were quite pretty :)
> > 
> > Thomas and I lamented that we were getting tired of seeing stuff like
> > this, and it was about time that we added the proper code to the kernel
> > to provide everything that would be needed in order to write PCI drivers
> > in userspace in a sane manner.  Really all that is needed is a way to
> > handle the interrupt, everything else can already be done in userspace
> > (look at X for an example of this...)
> 
> What about portable access to the PCI DMA API from userspace?

It currently does not provide this, but if you know how your card works,
I'm pretty sure you can get this working without such an interface.

If you wish to add this functionality, to make it easier, that would be
great.

> > Thomas mentioned that he had code to do all of this working in some
> > customer sites already and that he would get it to me.
> > 
> > Fast forward to OLS of this year, and I bugged Thomas to send me the
> > code.  He did, and then I sat on it for a while longer...
> > 
> > So, here's the code.  I think it does a bit too much all at once, but it
> > is an example of how this can be done.  This is working today in some
> > industrial environments, successfully handling hardware controls of very
> > large and scary machines.  So it is possible to use this interface to
> > successfully build your own laser wielding robot, all from userspace,
> > allowing you to keep your special-secret-how-to-control-the-laser
> > algorithm closed source if you so desire.
> > 
> > In looking at the proposed kevent interface, I think a few things in
> > this proposed interface can be dropped in favor of using kevents
> > instead, but I haven't looked at the latest version of that code to make
> > sure of this.
> > 
> > And the name is a bit ackward, anyone have a better suggestion?
> 
> Well, if it's focused on industrial controls like it appears from
> the code here then the name is fine. If it's a starting point to
> become someting more generic then User Space Driver (USD) subsystem
> might be nice.
> 
> A more generic system would go a long way to get rid of the dubious
> secret-sauce binary kernel modules that are popular in embedded
> linux projects. 

It's not focused on industrial controls at all, that just happens to be
the name of it right now, as that is why it was written.  It is much
more generic than that.

"USD" is a bit too close to "USB" for a name.  Any other ideas?

> > Thomas has also promised to come up with some userspace code that uses
> > this interface to show how to use it, but seems to have forgotten.
> > Consider this a reminder :)
> 
> That would be nice to see. I can't see how devices and drivers
> are registered from user space with what's here. I see
> iio_register_device() exported but no clue how userspace tells
> the kernel to claim a device or register an iio driver.

His posted example should show you how this all works together.

thanks,

greg k-h
-
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/

Powered by blists - more mailing lists