The Role of the Device Driver

As a programmer, you are able to make your own choices about your driver, and choose an acceptable trade-off between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is "flexible," we like this word because it emphasizes that 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) and "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. 机制和策略之间的区别是 Unix 设计背后的最佳理念之一。 大多数编程问题确实可以分为两部分：“要提供哪些功能”（机制）和“如何使用这些功能”（策略）。 如果这两个问题由程序的不同部分解决，或者甚至完全由不同的程序解决，则软件包更容易开发和适应特定需求。

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. 例如，图形显示的 Unix 管理分为 X 服务器（了解硬件并为用户程序提供统一接口）和窗口和会话管理器（在不了解硬件的情况下执行特定策略）。人们可以在不同的硬件上使用同一个窗口管理器，不同的用户可以在同一个工作站上运行不同的配置。即使是完全不同的桌面环境，例如 KDE 和 GNOME，也可以在同一个系统上共存。另一个例子是 TCP/IP 网络的分层结构：操作系统提供套接字抽象，它不执行有关要传输的数据的策略，而不同的服务器负责服务（及其相关策略）。此外，像 ftpd 这样的服务器提供了文件传输机制，而用户可以使用他们喜欢的任何客户端；命令行和图形客户端都存在，任何人都可以编写新的用户界面来传输文件。

Where drivers are concerned, the same separation of mechanism and policy applies. The floppy driver is policy free—its 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. 在编写驱动程序时，程序员应该特别注意这个基本概念：编写内核代码来访问硬件，但不要将特定的策略强加给用户，因为不同的用户有不同的需求。 驱动程序应该处理使硬件可用的问题，将有关如何使用硬件的所有问题留给应用程序。 如果驱动程序提供对硬件功能的访问而不增加约束，那么它是灵活的。 然而，有时必须做出一些政策决定。 例如，数字 I/O 驱动程序可能只提供对硬件的字节范围访问，以避免处理单个位所需的额外代码。

You can also look at your driver from a different perspective: it is a software layer that lies between the applications and the actual device. This privileged role of the driver allows the driver programmer to choose exactly how the device should appear: different 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 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. 无策略驱动程序具有许多典型特征。 其中包括对同步和异步操作的支持、多次打开的能力、利用硬件全部功能的能力以及缺少软件层来“简化事物”或提供与策略相关的操作。 这类驱动程序不仅对最终用户更好地工作，而且结果也更容易编写和维护。 无策略实际上是软件设计者的共同目标。

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. 事实上，许多设备驱动程序与用户程序一起发布，以帮助配置和访问目标设备。 这些程序的范围可以从简单的实用程序到完整的图形应用程序。 示例包括 Tunelp 程序，它调整并行端口打印机驱动程序的操作方式，以及作为 PCMCIA 驱动程序包一部分的图形 cardctl 实用程序。 通常还提供客户端库，它提供不需要作为驱动程序本身的一部分实现的功能。

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. 本书的范围是内核，所以我们尽量不处理策略问题或应用程序或支持库。 有时我们会讨论不同的策略以及如何支持它们，但我们不会详细介绍使用设备的程序或它们执行的策略。 但是，您应该了解，用户程序是软件包的组成部分，即使是无策略的软件包也随配置文件一起分发，这些配置文件将默认行为应用于底层机制。