LWN: Comments on "UIO: user-space drivers"

UIO: user-space drivers

shankun — Fri, 05 May 2017 07:01:45 +0000

whether to consider the multiple irqs ?

UIO: user-space drivers

nixscripter — Sun, 13 Dec 2009 19:38:46 +0000

It seems that UIO has made its way into the kernel code, so this discussion may be moot. But I just have a question: why not just require polling I/O in userspace?

If you can memory-map to RAM on the PCI bus now, you could just mmap() to a buffer under the driver's control instead. It could have not only device RAM, but also a flag for "interrupt occurred", which the application would clear, and a kernel space interrupt handler would set. You don't need a userspace interrupt handler at all.

"But that would be incredibly slow!" Yes, it would. And if you want more drivers for Linux, but don't want proprietary ones taking over, then offer a choice: userspace, closed source, and slow; or kernel space, open source, and fast. If that hardware engineer doesn't know about kernel hacking, then he should make it open source, and it will be fixed by people who know the kernel inside out. That's the idea behind an open-source project, right?

However, for those less political, UIO does seem a good solution.

UIO: user-space drivers

dlang — Wed, 07 Oct 2009 18:28:32 +0000

being designed to worth with is NOT the same as being derived from

if it was then every windows program would be derived from windows (after all, what other OS implements those system calls? SAMBA doesn't count as it is explicitly a copy of the windows API)

as such the license of the kernel is irrelevant for UIO simply because it is userspace and is using the defined interface.

UIO: user-space drivers

etienne_lorrain@yahoo.fr — Wed, 07 Oct 2009 09:55:32 +0000

> This dangerously seems like an atempt to be able to create proprietary drivers and bypass the GPL.

Probably only me, probably because IANAL, but I fail to see how an UIO driver would not be a derivative work of the kernel.
That would obviously be different if this interface was implemented in *BSD, Solaris, Windows... but I do not see that being the intent.
And implementing a GPL layer to connect a non-GPL driver would not change that the non-GPL driver is a derivative work of a GPL driver, which is a derivative work of the kernel.
Now if the law were applied...

Printer drivers

Nisok — Tue, 06 Oct 2009 09:07:32 +0000

Hi Richard
Could you please give me these GPL drivers?

UIO: user-space drivers

wangting@gmail.com — Thu, 03 Sep 2009 01:48:34 +0000

I think Andrew Morton's concern is reasonable, maybe user mode driver is used mainly for closed-source drivers. We need to encourage people to free their software!

UIO: user-space drivers

ofranja — Fri, 19 Oct 2007 03:22:29 +0000

Companies which do not want their work to become GPL'ed just need to make 
a tiny little "wrapper" driver inside the kernel, and then implement 
everything that matters in the userspace. In some (not to say many) 
scenarios, this approach actually is much better and saner than 
implementing everything in the kernel driver. 
 
BTW, one thing "home Linux users" should remember is that Linux is not 
strong in the home PCs as it is strong in the server market. Many 
companies in that scenario do not care about openess of some driver, as 
long as it works and/or you (the seller) fix it in case it breaks. 
Sometimes they prefer not having the source code and buy from someone who 
is more expensive, because the solution is better and more complete. 
 
IMHO, keeping this UIO infrastructure out of the kernel fearing a "binary 
takeover" would be like keeping FUSE out of the kernel fearing 
"proprietary filesystems" from taking over Linux: something we should not 
be afraid of. 
 
And that's it.

Printer drivers

Richard_J_Neill — Wed, 10 Oct 2007 02:36:51 +0000

It should also be easier to reverse-engineer a userspace driver by just watching what it does. What is *really* nasty are binary drivers with a dependency on a specific (usually 3-years obsolete) kernel version.

For example, I bought an expensive ($500) fast 32-bit parallel I/O card 4 years ago, which claimed to have Linux support. This turned out to be "but only on RedHat 7.3 with the default kernel". In the end, we threw out the hardware. Actually, we replaced it with another "Linux-supported" hardware item, called a QuickUSB. This also had only a binary driver, but it used libusb, and we were able to reverse-engineer it to write a GPL-driver. (But it still wasn't good enough in the end).

UIO: user-space drivers

vphirric — Sun, 29 Jul 2007 21:43:59 +0000

Hear hear -- and may I also add that there are lots of specialized little hardware widgets that need software control that simply do not present a character- or block- device paradigm. If your widget is some bizzare one-shot FPGA interface or the like, the existence of this kind of infrastructure is huge help. Thanks much!

Printer drivers

ringerc — Mon, 23 Jul 2007 05:54:42 +0000

Some printer drivers are implemented in userspace and are not GPL.

The Samsung monstrosity recently covered by LWN is one such example. Another is the CUPS filter & backend shipped with the Xerox CentreWare suite, which is a living fossil, complete with dropping its self into random bits of /usr .

This issue concerns me too. On one hand, I'd prefer a closed source driver to no driver much of the time. On the other hand, if it's a bad driver it's not much better than no driver at all, and lacking the ability to fix or debug it because it's just a binary blob would be seriously annoying.

Hopefully this won't lead to a large surge in closed source userspace drivers. Still, if it does, at least they'll have to work harder to bring the machine down.

UIO: user-space drivers

hjkoch — Tue, 05 Jun 2007 10:15:52 +0000

As one of the main authors of UIO I can tell you that license issues were
never an important topic in our discussions. Our judge and jury is Greg
Kroah-Hartman, who is certainly not in favor of proprietary drivers. Our
target audience are programmers in industry, who have to write a driver
for an exotic card that could never make it into mainline. They're neither
kernel experts nor do they write good code (they don't have the time).
With UIO, they can let somebody else write the 150 lines of kernel code,
which _has_ to be GPL, and the big part can be done in userspace, with the
same tools and knowledge needed for their application, anyway. Yes, in
userspace it's possible to choose a different license, but that's not
UIO's fault or intention. It's been like this since Linux exists.

UIO: user-space drivers

hjkoch — Tue, 05 Jun 2007 10:01:28 +0000

Yes. And if it's an in-kernel driver, they either violate the GPL and/or
hack up something completely unmaintainable. UIO gives them the
possibility to do the dirty part of the driver in user space, and it can
simply become a part of their application. They can use the tools they
know, and don't have kernel version issues. And they can choose any
license they want for the userspace part. BTW, all userspace drivers I'm
aware of are GPL.

UIO: user-space drivers

nlucas — Fri, 04 May 2007 17:19:04 +0000

The kind of user-space drivers people were doing don't compare with the drivers you will be able to do, even if you probably can't do a user-space graphics driver.

Also note that I'm not a GPL zealot, but I agree with the "doomsday scenario for linux in a binary world" (OTOH I don't buy the "stable API nonsense").

Other than that, I don't have problems running the nvidia drivers at my home PC (the few games I still play need 3D).

UIO: user-space drivers

zlynx — Fri, 04 May 2007 16:11:52 +0000

So what if people do use it to bypass the GPL? Developers were doing user-space drivers *anyway*. And doing it badly in most cases.

It depends on if your goal is to write an excellent, open OS kernel or to force all software in the world to become GPL.

UIO: user-space drivers

nlucas — Fri, 04 May 2007 14:43:13 +0000

I'm with you. It sounds more like an excuse than a real reason.

This dangerously seems like an atempt to be able to create proprietary drivers and bypass the GPL.

On one hand I understand the good of having user-space drivers, but on the the other hand I don't see how that can be done and not create this loophole.

UIO: user-space drivers

xav — Thu, 03 May 2007 20:06:09 +0000

People in the embedded space don't do prototypes. They hack something until it works, then it's done.