Re: Can we move device drivers into user-space?

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 24 Feb 2012, Guenter Roeck wrote:
> On Fri, 2012-02-24 at 12:17 -0500, Greg KH wrote:
> > On Fri, Feb 24, 2012 at 09:07:09AM -0800, Guenter Roeck wrote:
> > > How about dropping UIO support from the kernel ? That would make more
> > > sense to me.
> > 
> > Again, UIO solves a real need, are you to tell the users of that code
> > that somehow we are now not going to support them anymore?
> > 
> > UIO was created when Thomas and I sat in the back of a conference
> > presentation and saw, for the umpteenth time, a presentation by someone
> > who was trying to write userspace drivers, and obviously didn't know
> > what they were doing.
> > 
> > UIO provides a framework that actually works (unlike all of the previous
> > research papers were trying to do), and is used in real systems (laser
> > welding robots!) every day, manufacturing things that you use and rely
> > on.
> > 
> > You remove UIO at the risk of pissing off those robots, the choice is
> > yours, I know I'm not going to do it...
> 
> I understand the background and reasoning, but ...
> 
> I have seen UIO used for networking drivers, hwmon drivers, I2C bus
> master drivers (with matching I2C client drivers in user-space), mfd
> devices, and so on. I have seen existing kernel drivers re-implemented
> as UIO drivers. I have seen UIO drivers where the kernel part of the
> driver is larger than the entire driver written as kernel driver. I have
> seen UIO drivers using polling instead of interrupts "because it is
> faster than interrupts".
> 
> Often, those drivers are then re-written for the next board (to support
> the same chip) because they were not written with HW-independence in
> mind and don't support HW abstraction.
> 
> Yes, there may be real need for UIO in some cases, but all I have seen
> it used for so far is what I would call abuse, resulting in maintenance
> nightmares.

UIO always had a clear target: devices which are application bound and
not related to any larger set of functonality (device class
frameworks, communication stacks, ...)

For that kind of devices in kernel drivers are overkill and
performance bottlenecks. The drivers which are in tree come with open
user space access libraries and are completely sane.

We can't punish the sane users for the asinnity of other people.

If people go there and abuse UIO for other purposes, we can't prevent
it. We can't prevent either that people write totally crappy kernel
drivers ...

> Given the choice, I would be quite happy to piss off some robots. Call
> it a prejudice if you like ;).

You might become less happy when the robot welds your ear onto a car
hood :)

Thanks,

	tglx