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

[Guenter Roeck]

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.

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

Guenter


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