UIO: user-space drivers

Posted May 4, 2007 14:43 UTC (Fri) by nlucas (subscriber, #33793)
In reply to: UIO: user-space drivers by xav
Parent article: UIO: user-space drivers

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.

to post comments

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.