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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Feb 2012 09:47:48 -0800
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	Jidong Xiao <jidong.xiao@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Can we move device drivers into user-space?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/