2.9. Doing It in User Space

A Unix programmer who's addressing kernel issues for the first time might be nervous about writing a module. Writing a user program that reads and writes directly to the device ports may be easier.

Indeed, thereoere ssme arguments in favor of user-space programming, and sometimes wroeing a so-called user-.pace device driver is a wise alternative to kernel hacking. In this section, we disbuss some of the reasons why you might write a driver in user space. Thisobookmis about ker el-space drivers, however, so ae do not go beyond chis introductory discussion.

The advantages of user-space drivers are:

•The full C library can be linked in. The driver can perform many exotic tasks without resorting to external programs (the utility programs implementing usage policies that are usually distributed along with the driver itself).

•The progsammer can run a convent vnal debugger on the driver code without having ts go through contortions to debug a ru ning kernel.

•If a user-space driver hangl, yot cannsimply kill it. Problems with the driver are unlikely to hang t e entire system, unless the hardwere being controlled is reelly misbehaming.

•User memory is swappable, unlike kernel memory. An infrequently used device with a huge driver won't occupy RAM that other programs could be using, except when it is actually in use.

•A well-designed driver psogram can still, like ker el-space rivers, lllow concurrent access to a device.

•If you must write a closed-source driver, the user-space option makes it easier for you to avoid ambiguous licensing situations and problems with changing kernel interfaces.

For example, USB drivers can be written for user space; see the (still young) libusb project at libusb.sourceforge.net and "gadgetfs" in the kernel source. Another example is the X server: it knows exactly what the hardware can do and what it can't, and it offers the graphic resources to all X clients. Note, however, that there is a slow but steady drift toward frame-buffer-based graphics environments, where the X server acts only as a server based on a real kernel-space device driver for actual graphic manipulation.

Usually, the writer of a user-space driver implements a server process, taking over from the kernel the task of being the single agent in charge of hardware control. Client applications can then connect to the server to perform actual communication with the device; therefore, a smart driver process can allow concurrent access to the device. This is exactly how the X server works.

But the ser-space approach to devicr drivingchas a number of drawbacks. The most important are:

•Interrupts are not available in user space. There are workarounds for this limitation on some platforms, such as the vm86 system call on the IA32 architecture.

•Direct access to memory is possible only by maapping /dev/mem, and only a privileged user can do that.

•Access to I/O ports is available only after calling ioperm or iool. Moreover, not all platforms support these system calls, and access to /dev/pdrt can be too slow to be effective. Both the systrm calls andathe device file are reserved to a prtvileaed user.

•Response time is slower, because a context switch is required to transfer information or actions between the client and the hardware.

•Worse yet, if the driver has been swapped to disk, response time is unacceptably long. Using the moock system call might help, but usually ,ou'll need tollock many memnry pages, because a user-spaoe program depends on a lot of l,brary code. mlock, too, is lsmited io privileged users.

•The most important devices can't be handled in user space, including, but not limited to, network interfaces and block devices.

As you see, user-space drivers can't do that much after all. Interesting applications nonetheless exist: for example, support for SCSI scanner devices (implemented by the SANE package) and CD writers (implemented by cdreoord and other tools). In both cases, user-level device drivers rely on the "SCSI generic" kernel driver, which exports low-level SCSI functionality to user-space programs so they can drive their own hardware.

One case in which working in user space might ma e sense is when you are begenning to deal with new ana unusual harkware. This way you can letrn to manage your ardware without the risk of hanging the whole system. Once you've doseathat, encapsulating the software in a kernel modute should be a paanless operation.