Weekly Edition
Return to the Kernel page
| |||||||||||||
Support for drivers in user space
Device drivers are generally done inside the kernel for the usual reasons
of performance and control. There are times, however, when the ability to
run a device driver in user space is helpful. These include situations
where the code is far too large to go into the kernel (X.org, for example)
and where the author of the driver does not wish to
place the code under the GPL. Some types of drivers (such as those for USB
devices) are easily run in user space now, but others can be a bit more
challenging. Very few PCI drivers, for example, are written in user space.
Thomas Gleixner has written an interface module which may help to change that situation. With this code in place, PCI drivers (some of them, at least) can be written almost entirely in user space, with only a small stub module loaded into the kernel. That module has two specific jobs to carry out. The first is to register the device to be driven, with a couple of bits of important information. To that end, it should fill out an iio_device structure, which contains the following fields:
struct iio_device {
char *name;
char *version;
unsigned long physaddr;
void *virtaddr;
unsigned long size;
long irq;
irqreturn_t (*handler)(int irq, void *dev_id, struct pt_regs *regs);
ssize_t (*event_write)(struct file *filep, const char __user * buf,
size_t count, loff_t *ppos);
struct file_operations *fops;
void *priv;
/* ... */
};
The first part of the structure provides information about the hardware to be driven - its name, where its I/O memory area lives (physaddr), where that area has been mapped into the kernel (virtaddr), its size, and the interrupt being used by the device. If virtaddr is zero, then physaddr is interpreted as the beginning of a range of I/O ports, rather than a memory address. The fops field provides the file operations for the device; normally, they are set to the generic versions provided by the IIO (for "industrial I/O") driver: iio_open(), iio_read(), iio_mmap(), etc. With this setup, the driver can create a basic device which allows a user-space program to read from or write to device memory (or ports). I/O memory can also be mapped into user space. The capabilities described thus far are not all that different from what can be done with /dev/mem; the main difference is that the stub driver can enable the PCI device and perform any other needed initialization. The real hitch in writing user-space PCI drivers, however, has been in the handling of interrupts. There is currently no way to write a user-space interrupt handler, and the IIO patch doesn't really change that. Instead, the stub driver is expected to provide a minimal interrupt handler of its own. This handler is needed because every device requires its own specific interrupt acknowledgment ritual. The kernel must respond quickly to an interrupt and give the device the attention it craves so that said device will stop asserting the interrupt. After that, any additional processing can be done at relative leisure. So, once the handler provided with the stub driver acknowledges the interrupt, the rest of the work can normally be done by the user-space driver. All that is needed is to let this driver know that the interrupt has happened. The IIO module provides a couple of mechanisms for that purpose. One is a second device node associated with the device; whenever an interrupt happens, a byte can be read from this "event device." So a user-space driver can simply block on a read from that device, or it can use poll() in more complicated situations. It is also possible for the user-space driver to receive SIGIO signals when an interrupt happens, but using signals will normally increase the ultimate response time to the interrupt. So, to make all this happen, the stub driver provides a minimal interrupt handler in the handler() field of the iio_device structure. When an interrupt happens, the IIO module will call this handler; if it returns IRQ_HANDLED, user space will be notified. If the stub driver provides an event_write() function, that function will be called in response to a write operation on the event device. This capability can be used to further control the kernel-space response to interrupts, request that interrupts be masked, etc. Readers who think that the event mechanism shares some features with the proposed kevent subsystem are right. It is probable that the IIO event handling code will be rewritten to use kevents, if and when kevents are merged into the mainline. Meanwhile, however, the IIO driver works. Thomas has posted an example driver (or parts of one, anyway) to show how this mechanism can be used. The real question which appears to be on a number of minds, however, is: could ATI and nVidia use IIO to move their drivers out of the kernel. Only those vendors can answer that question, however, so, until they say something, nobody really knows. (Log in to post comments)
Support for drivers in user space Posted Sep 7, 2006 0:53 UTC (Thu) by NCunningham (guest, #6457) [Link] Sigh. If you implement your drivers in userspace, you can simultaneouslytell your users to forget about suspending to disk, and possibly to ram.
Support for drivers in user space Posted Sep 7, 2006 2:30 UTC (Thu) by gregkh (subscriber, #8) [Link] Not true at all, you have to have a tiny kernel piece for this frameworkto work properly, and just add the proper PCI suspend / resume portions of the pci framework and it should work just fine.
Support for drivers in user space Posted Sep 14, 2006 9:07 UTC (Thu) by quintesse (subscriber, #14569) [Link] Hi Nigel (*), could you expand on this? Would it really be impossible to do power management and such things if (most of) the driver code is moved to user space and why?
*) See http://www.suspend2.net for those who don't know Nigel
Support for drivers in user space Posted Sep 7, 2006 6:49 UTC (Thu) by bboissin (subscriber, #29506) [Link] Although there seems to be a consensus among kernel devs that if it is in userspace then the GPL is not applicable.Doesn't a driver in userspace constitute a derivative work from the kernel (especially since the API is specific to Linux) ?
The note from Linus in the COPYING file only says:
Maybe someone can enlighten me (please no flames).
Support for drivers in user space Posted Sep 7, 2006 9:33 UTC (Thu) by pphaneuf (guest, #23480) [Link] I'd say this is correct. But this device driver is incomplete, you still need to create a kernel module that adds the missing interrupt handler. That part will still need to comply with whatever the licensing rules for kernel modules are.
This is not a flame... Posted Sep 7, 2006 13:19 UTC (Thu) by hummassa (subscriber, #307) [Link] Google for abstraction, filtration and comparison.After doing so, my opinion: no, a device driver is not necessarily a derivative work of the kernel. But, as the sibling post states, the kernel module that handles the interrupts (and possibly suspending/resuming) probably _is_ a derivative work of the kernel.
Support for drivers in user space Posted Sep 14, 2006 8:57 UTC (Thu) by lgb (guest, #784) [Link] Well yes, I guess, the kernel part of these drivers should be released as GPL code. However, the bulk of the code is in user space ... If you were right, an average user space app is also a derivative work, since it's not only uses system calls, but may also use /dev or /proc or even /sys entries, besides syscalls. This splitted driver model just do this: a to-be-GPL'ed kernel part, and a user space part which needn't released as GPL.
Support for drivers in user space Posted Sep 14, 2006 15:05 UTC (Thu) by gwg (guest, #20811) [Link] Something that seems to be overlooked most of the time in thesediscussions, is that the GPL applies to "work based on the Program", and there are more types of such work that just derived work.
Another sort of work is a collective (or compilation) work.
For a work to be a collective work, I don't think that it
If a user mode driver is arranged to work with the kernel
Support for drivers in user space Posted Sep 14, 2006 21:54 UTC (Thu) by zlynx (subscriber, #2285) [Link] That may possibly be a valid legal argument, but its irrelevant to Linux, since it has always exempted user-space programs from any Linux-related license requirement.
Support for drivers in user space Posted Sep 15, 2006 4:37 UTC (Fri) by gwg (guest, #20811) [Link] Linus's explanation in the Linux "COPYING" file is unclear. In the relevantsentence he states that "this copyright does *not* cover user programs that use kernel services by normal system calls", which might be construed as meaning that the Kernel copyright does not regard user programs as ever being part of a "work based on the Program", or it could mean that no copyright is claimed over user programs just because they make system calls, or both, (these being two different things, one being the scope of a collective work, the other being the copyright on the user program).
But then he goes on to say " - this is merely considered normal use of the
Support for drivers in user space Posted Sep 15, 2006 16:42 UTC (Fri) by zlynx (subscriber, #2285) [Link] One more point. Your argument is clearly not the intent of Linus' exception.
For example, if you are correct, a Linux LiveCD with Unreal Tournament included is violating the GPL.
Unreal Tournament communicates with the GPU directly (well, through OpenGL direct rendering libraries), just as a user-space driver would.
So if one is violating the GPL by your argument, so is the other, and that is clearly ridiculous.
Support for drivers in user space Posted Sep 16, 2006 2:32 UTC (Sat) by gwg (guest, #20811) [Link] It's hard to say from Linus's statement in the COPYING file alone, what his intention was.From common usage, you may regard such an interpretation as ridiculous, but that doesn't somehow invalidate the interpretation of the licence. If a different contributor to the Linux kernel wanted to make the interpretation I've made, then they could well take someone distributing something like Unreal Tournament on a LiveCD to court, and see if the court agrees that it's a collective work, and falls under the requirements of the GPL, as being a "work based on the Program", and that Linus's disclaimer only applies to derived works. I certainly regard anyone making use of my GPL licences code as being in violation of the licence, if they release a collective work that does not itself comply with the GPL licence (but then I don't have a Linus like disclaimer in my copy of the GPL).
Support for drivers in user space Posted Sep 15, 2006 18:14 UTC (Fri) by efexis (guest, #26355) [Link] I don't think so; you can communicate with something without being a derivative work of it. Maybe you could write a portable driver, where the majority of the code can run under different OS's, that just uses a small glue to connect to the actual kernel. The driver itself could maybe run under Linux, Solaris, and Windows... but does that make it a derivate of all three?
Support for drivers in user space Posted Sep 7, 2006 6:58 UTC (Thu) by flewellyn (subscriber, #5047) [Link] 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.
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?
Support for drivers in user space 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.
Support for drivers in user space 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?
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.
Tainting Posted Sep 7, 2006 16:10 UTC (Thu) by feyd (guest, #26860) [Link] There should be a way for the userspace driver to state its license and the kernel should be tainted if it is not GPL compatible.
Tainting Posted Sep 8, 2006 18:52 UTC (Fri) by giraffedata (subscriber, #1954) [Link] There should be a way for the userspace driver to state its license and the kernel should be tainted if it is not GPL compatible. Toward what end? The stated purpose of the existing taint flag is to warn a kernel engineer who might try to diagnose and fix a kernel problem that he doesn't have all the source code, so he might want to refuse. But the system call interface is supposed to be a thick enough barrier that kernel engineers don't normally require source code for what's running on the other side of it in order to work on the kernel.
Tainting Posted Sep 12, 2006 19:08 UTC (Tue) by feyd (guest, #26860) [Link] The userspace PCI driver can cause problems on PCI bus or memory corruption and thats hard to debug if the source is not available.
Support for drivers in user space Posted Sep 7, 2006 18:56 UTC (Thu) by mycroft (guest, #40381) [Link] Very interesting read. You might also consider the other reasons for wanting a user level device driver (ULDD):
o Improved development time
In regards to handling interrupts. Have you looked at Peter Chubb's
This interest in ULDD's is good to see as it is an area of
benefits of user space Posted Sep 8, 2006 3:11 UTC (Fri) by pjm (subscriber, #2080) [Link] Indeed: I'd have thought that one of the primary reasons for userspace drivers is for the greater fault isolation. Many device drivers have noticeably lower quality code and tend to have more bugs per line of code than the rest of the kernel. Moving to userspace (separate address space, more familiar programming environment) reduces the harm that can be done: buggy userspace device drivers can still bring down the system, but there's less opportunity for bugs to silently corrupt unrelated parts of memory (for example).
(Device drivers tend to be written by people with knowledge of / access to the device in question, and are often not regular kernel developers. The limited pool of people with access to a particular device means that fewer eyes pass over the code, and in particular that fewer exceptionally good programmers look at the code as some of the rest of Linux.)
Power Management Posted Sep 14, 2006 6:08 UTC (Thu) by ringerc (subscriber, #3071) [Link] I just hope bus power management was carefully considered in this design - especially, as one poster mentioned, suspend and resume. It would be EXTREMELY frustrating to see a new PCI device driver API arrive without well thought out interfaces for consistent power managment, given that a new API is the perfect opportunity to introduce strong requirements on those issues.
Given that everything from supercomputers to smartphones cares a lot about power managment these days, it'd be very silly not to plan for it.
|
|||||||||||||