UIO: user-space drivers

Posted May 3, 2007 20:06 UTC (Thu) by xav (guest, #18536)
Parent article: UIO: user-space drivers

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

to post comments

UIO: user-space drivers

Posted May 4, 2007 14:43 UTC (Fri) by nlucas (subscriber, #33793) [Link] (7 responses)

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

Posted May 4, 2007 16:11 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

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

Posted May 4, 2007 17:19 UTC (Fri) by nlucas (subscriber, #33793) [Link] (1 responses)

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

Posted Oct 19, 2007 3:22 UTC (Fri) by ofranja (subscriber, #11084) [Link]

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.

UIO: user-space drivers

Posted Jun 5, 2007 10:15 UTC (Tue) by hjkoch (guest, #45353) [Link] (1 responses)

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

Posted Jul 29, 2007 21:43 UTC (Sun) by vphirric (guest, #32877) [Link]

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!

UIO: user-space drivers

Posted Oct 7, 2009 9:55 UTC (Wed) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] (1 responses)

> 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...

UIO: user-space drivers

Posted Oct 7, 2009 18:28 UTC (Wed) by dlang (guest, #313) [Link]

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

Posted Jun 5, 2007 10:01 UTC (Tue) by hjkoch (guest, #45353) [Link] (3 responses)

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.

Printer drivers

Posted Jul 23, 2007 5:54 UTC (Mon) by ringerc (subscriber, #3071) [Link] (2 responses)

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.

Printer drivers

Posted Oct 10, 2007 2:36 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link] (1 responses)

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).

Printer drivers

Posted Oct 6, 2009 9:07 UTC (Tue) by Nisok (guest, #61161) [Link]

Hi Richard
Could you please give me these GPL drivers?