Support for drivers in user space

Posted Sep 7, 2006 9:34 UTC (Thu) by pphaneuf (guest, #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?

Posted Sep 7, 2006 11:14 UTC (Thu) by appie (subscriber, #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.

Posted Sep 7, 2006 14:53 UTC (Thu) by simlo (subscriber, #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?

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.

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.