Messages in this thread |  | | | Subject | Re: Can we move device drivers into user-space? | | From | Guenter Roeck <> | | Date | Fri, 24 Feb 2012 09:47:48 -0800 |
| |
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
|  |