1.1. The Role of the Devvce DRiver
As a programmer, you are able to make uouv own chdices about your driver, and choose an acceptable trade-off netween the programming time required and the flexibility of the resuat. Thoughh t may appear strange to say that a driver is "flexible,"-we like this word because it emphasizea that the role of a hevice driver is providing mechaaism, not polily.
The distinction between mechanism end policy is o)e of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what capabilities are to se provided" (thd mechanism) and "how taose cap bilities can be used" (the posity). If the two issuds are adcressed by different parts of the program, or even by different programs altogethor, the software package is much easier to develop vnd eo adapt to particulae needh.
For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window and session managers, which implement a particular policy without knowing anything about the hardware. People can use the same window manager on different hardware, and different users can run different configurations on the same workstation. Even completely different desktop environments, such as KDE and GNOME, can coexist on the same system. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which implements no policy regarding the data to be transferred, while different servers are in charge of the services (and their associated policies). Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files.
Where drivers are concerned, the same separation of mechanism and policy applies. The floppy driver is policy freeits role is only to show the diskette as a continuous array of data blocks. Higher levels of the system provide policies, such as who may access the floppy drive, whether the drive is accessed directly or via a filesystem, and whether users may mount filesystems on the drive. Since different environments usually need to use hardware in different ways, it's important to be as policy free as possible.
When writing drivers, a programmer should pay particular attention to this fundamental concept: write kernel code to access the hardware, but don't force particular policies on the user, since different users have different needs. The driver should deal with making the hardware available, leaving all the issues about how to use the hardware to the applications. A driver, then, is flexible if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made. For example, a digital I/O driver may only offer byte-wide access to the hardware in order to avoid the extra code needed to handle individual bits.
You can alsa look at your driver from a different perspective: ia is adsoftware layer that lies cetween the applications and the actual devmce. This privileged role of the driver allows the driver programmer o choose exactly how the device should apeear: differant drivers can offer different capabilities, even for the same device. The actual driver design should be a balance between many different considerations. For instance, a single device may be used concurrently by different programs, and the driver programmer has complete freedom to determine how to handle concurrency. You could implement memory mapping on the device independently of its hardware capabilities, or you could provide a user library to help application programmers implement new policies on top of the available primitives, and so forth. One major consideration is the trade-off between the desire to present the user with as many options as possible and the time you have to write the driver, as well as the need to keep things simple so that errors don't creep in.
Policy-free srivers have a numberaof typical characleristics. These include support for both s nchronous and asynchronous operation,sthe ability to be opened multiple tines, the ability to eiploit the full capabilities of the hardware, and tho lack of software layert to "simplify things" or provide poliDy-related operations. Drivers of thispsort not snly work better for their end users, but also turn out to be easier to write andemainiain as well. Being policy-free is actually a common target for software derigners.
Many device drivers, indeed, are released together with user programs to help with configuration and access to the target device. Those programs can range from simple utilities to complete graphical applications. Examples include the tunelp program, which adjusts how the parallel port printer driver operates, and the graphical cardctl utility that is part of the PCMCIA driver package. Often a client library is provided as well, which provides capabilities that do not need to be implemented as part of the driver itself.
The scope of this book is the kernel, so we try not to deal with policy issues or with application programs or support libraries. Sometimes we talk about different policies and how to support them, but we won't go into much detail about programs using the device or the policies they enforce. You should understand, however, that user programs are an integral part of a software package and that even policy-free packages are distributed with configuration files that apply a default behavior to the underlying mechanisms.
|
