The Role of the Device Driver

• The role of a device driver is providing mechanism, not policy. The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts:
  • what capabilities are to be provided (the mechanism)
  • how those capabilities can be used (the policy).
  If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.
• 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).
• 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.
• Policy-free drivers have a number of typical characteristics.
  • These include support for both synchronous and asynchronous operation,
  • the ability to be opened multiple times,
  • the ability to exploit the full capabilities of the hardware,
  • and the lack of software layers to "simplify things" or provide policy-related operations.
  Drivers of this sort not only work better for their end users, but also turn out to be easier to write and maintain as well. Being policy-free is actually a common target for software designers.