User: Password:
|
|
Subscribe / Log in / New account

Support for drivers in user space

Support for drivers in user space

Posted Sep 7, 2006 6:58 UTC (Thu) by flewellyn (subscriber, #5047)
Parent article: Support for drivers in user space

This is really not a good idea. If we move drivers out of kernel space, we lose not just performance, but we lose some of the power of the GPL as a tool to keep the system free. Go down this road, and we may wind up with a situation where the kernel is free software, but the drivers for hardware are not. In other words, a non-free system.


(Log in to post comments)

Support for drivers in user space

Posted Sep 7, 2006 9:34 UTC (Thu) by pphaneuf (subscriber, #23480) [Link]

I wonder how the HURD (with its microkernel design and its userspace modules) deals with that issue? Or maybe they just didn't think of this possibility?

Support for drivers in user space

Posted Sep 7, 2006 11:14 UTC (Thu) by appie (guest, #34002) [Link]

Indeed, doesn't this open up a road to scenarios like Linux in a binary world... a doomsday scenario as well ?
As with all inventions, there's a good side and a Dark Side to be considered.
The whole driver area is, i'm afraid, unfortunately one where coders do have to consider politics et al besides, well, coding.

Support for drivers in user space

Posted Sep 7, 2006 14:53 UTC (Thu) by simlo (guest, #10866) [Link]

I think this is a good compromise:
An open source, GPL'ed, in-kernel driver very often perform better than the closed source user-space one. Thus vendors providing open source drivers gets an etch over those who do not want to open their driver. So Linux users not so worried about having a 100% free system will be able to use the hardware but will tend to choose one from a vendor providing an open driver, because it performs better.

And it is not as big a problem for the kernel development since the interface to userspace can more easily be keeped stable than an internal API.

Having a closed source driver running in userspace is a good starting point for reverse engineering it, too.

Esben

PS. How can you complain about a closed source driver and not complain about the BIOS? Or the closed source microcode in the processor?

Support for drivers in user space

Posted Sep 7, 2006 19:33 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

I think the reason people don't complain about the BIOS (more than they do; see LinuxBIOS) is that the BIOS could be considered part of the hardware. So could microcode in the processor.

If hardware manufacturers put the "sensitive" portions of their drivers in firmware, using Forth or something else compact to provide a programmable interface to the hardware, then they could release free drivers that just sent the necessary commands to the firmware. I don't think that would be objectionable, since, again, the firmware could be considered part of the hardware.

Maybe. I'm not a lawyer. (I would like to see free firmware, mind you, but I think free software is more important.)

Support for drivers in user space

Posted Sep 7, 2006 22:06 UTC (Thu) by man_ls (guest, #15091) [Link]

PS. How can you complain about a closed source driver and not complain about the BIOS? Or the closed source microcode in the processor?
Richard Stallman does. In fact many people do once they learn or figure out the problem. The reasoning goes: software you can change yourself should be free software, i.e. have source code available and allow distribution of modified versions.

People do not complain about the microcode in the processor, mind you, since it cannot be upgraded or changed; it can safely be considered hardware.

Support for drivers in user space

Posted Sep 8, 2006 10:26 UTC (Fri) by Los__D (guest, #15263) [Link]

Oh? http://freshmeat.net/projects/intelp6microcodeupdateutility/

Support for drivers in user space

Posted Sep 8, 2006 10:38 UTC (Fri) by man_ls (guest, #15091) [Link]

Oops! One more thing to worry about then...

Support for drivers in user space

Posted Sep 7, 2006 15:36 UTC (Thu) by sbishop (guest, #33061) [Link]

I think that this is a good idea because it is useful. Let me explain. I work with self-taught programming electrical engineers, and maintain a very simple USB driver for a tester we've developed to test our own hardware. I'm planning to switch to a user-space driver, though, as soon as possible, to make things much, much easier for my (eventual) replacement.

I could take Greg K-H up on his offer (to everyone in my situation, not just me personally) to have the kernel driver merged into the mainline. But the tester hosts are just now switching over to RHEL4 (with a 2.6.9 kernel). How long would it take before that merged driver came back around to us?

I have a friend who maintains a PCI driver, also for an internally used tester, at a different company. I'm sure he (and importantly, his boss) would be happy to go user-space.

License-wise, I'm with Linus. Enforce the GPL with respect to the kernel, but don't try to use it to force things on others beyond that. Free software can stand on its own merits.

Modularity and competition

Posted Sep 7, 2006 15:38 UTC (Thu) by copsewood (subscriber, #199) [Link]

I think this argument potentially confuses a technical with a political issue.

My view is that in both contexts modularity is good. In the licensing/political context, having modularity means that 2 pieces of software, or subsystems, or systems under 2 different free licenses or under free and proprietary licenses can communicate. Modularity makes competition between different implementations possible and evolution ensures survival of best working code (usually but not always free).

If a proprietary hardware manufacturer which doesn't want to disclose information to competitors through support of free software drivers can support Linux through a userspace driver this means those who have bought, or want to buy this hardware won't be totally discouraged by the lack of Linux support for it. If a second hardware manufacturer can achieve better performance with a GPL kernelspace driver this has the potential advantage of more Linux sales than the first manufacturers products. Unless there is competition for Linux related sales between them, neither manufacturer need bother.

Extending the argument to reductio ad absurdam, consider the case that the ideological purity of Linux requires that it doesn't communicate with any _system_ that uses non-free software, including Windows boxes using TCP/IP. In practice there are different levels of communication possible between software components, and genuine technical modularity and neutral and published interfacing standards such as TCP/IP not only leads to more reliable components and systems such as Linux and BSD, but this also creates niches leading to whole market ecosystems within which free software can flourish and grow.

So I think that having support for a generic Linux userspace device driver interface is an excellent idea, both for technical reasons in the sense of introducing a boundary protecting the overall system from buggy userspace code, and for the purpose of advancing the cause of free software as a political benefit through the incremental improvement this technical interface allows in the free software marketplace.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds