Re: [RFC] Simple userspace interface for PCI drivers

[Manu Abraham <abraham.manu@gmail.com>]

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...)


A while back, while we (myself and Andrew De Quincey) were struggling
with new DVB frontend devices that needed math operations to be
performed in the frontends themselves for frequency tracking / locking
etc, we found that eventually userspace was a much better place to have
such code, rather than being in kernel.

After quite some thoughts we found it would be much better to have them
implemented in userspace. We did finally draw up to some conclusions,
eventually.

We came up with some code eventually, but time was limited on our hands
that we went into discussion of the newer delivery systems that came
along, so development was a bit halted in that aspect.

http://www.thadathil.net/dvb/msg_transfer_interface
http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/v4l-dvb-user
http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/libdvbapi

> 
> 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?
> 
> 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 :)
> 
> Comments?


Being a bit excited and it is really interesting to have such a
proposal, it would simplify the matters that held us up even more,
probably. The name sounds fine though. All i was wondering whether there
would be any high latencies for the same using in such a context. But
since the transfers would occur in any way, even with a kernel mode
driver, i think it should be pretty much fine.


Manu


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/