6.1 Introduction

Note: the framework's obsolete name as ``device driver framework'' is historical baggage from its first client component, imported device drivers. Today, a more accurate name would be the ``OS Environment'' framework. It provides the API and glue used by all ``large'' encapsulated components (devices, networking, filesystems) imported from other operating systems. We'll change the name and documentation in the future.

A note on organization and content: this chapter really contains three quite separate parts: a general narrative about execution models, some very sketchy documentation of the ``up-side'' device interfaces, and the bulk covers the ``osenv'' interfaces. A later chapter (12) talks sketchily about the default implementation of the interfaces found here.

The OSKit device driver framework is a device driver interface specification designed to allow existing device drivers to be borrowed from well-established operating systems in source form, and used unchanged to provide extensive device support in new operating systems or other programs that need device drivers (e.g., hardware configuration management utilities). With appropriate glue, this framework can also be used in an existing operating system to augment the drivers already supported by the OS. (We believe it's possible to extend the framework to accomodate drivers in binary form.) This chapter describes the device driver framework itself; other chapters later in this document describe specific libraries provided as part of the OSKit that provide driver and kernel code implementing or supporting this interface.

The primary goals of this device driver framework are, in order from most to least important:

1. Breadth of hardware coverage. There is a tremendous range of common hardware available these days, each typically supporting its own device programming interface and requiring a special device driver. Device drivers for a given device are generally only available for a few operating systems, depending on how well-established the particular device and OS is. Thus, in order to achieve maximum hardware coverage, the framework must be capable of incorporating device drivers originally written for a variety of different operating systems.
2. Adaptability to different environments. This device driver framework is intended to be useful not only in traditional Unix-like kernels, but also in operating systems with widely different structures, e.g., kernels written in a ``stackless'' interrupt model, or kernels that run all device drivers as user mode programs, or kernels that do not support virtual memory.
3. Ease-of-use. It should be reasonably easy for an OS developer to add support for this framework to a new or existing OS. The set of support functions the OS developer must supply should be kept as small and simple as possible, and there should be few ``hidden surprises'' lurking in the drivers. In situations where existing device drivers supported by the OSKit have special requirements that the OS must satisfy in order to use them, these requirements are clearly documented in the relevant chapters.
4. Performance. In spite of the above constraints, device drivers should be able to run under this framework with as little unnecessary overhead as possible. Performance issues are discussed further in Section 6.5.

Since the most important goal of this framework is to achieve wide hardware coverage by making use of existing drivers, and not to define a new model or interface for writing drivers, it is somewhat more demanding and restricting in terms of OS support than would be ideal if we were writing entirely new device drivers from scratch. Other device driver interface standards, such as DDI/DKI and UDI, are not designed to allow easy adaptation of existing drivers; instead, they are intended to define and restrict the interfaces and environment used by new drivers specially written for those interfaces, so that these new drivers will be as widely useful as possible. For example, UDI requires all conforming drivers to be implemented in a nonblocking interrupt model; this theoretically allows UDI drivers to run easily in either process-model or interrupt-model kernels, but at the same time it eliminates all possibility of adapting existing traditional process-model drivers to be UDI conformant without extensive changes to the drivers themselves. Hopefully, at some point in the future, one of these more generic device driver standards will become commonplace enough so that conforming device drivers are available for ``everything''; however, until then, the OSKit device driver framework takes a compromise approach, being designed to allow easy adaptation of a wide range of existing drivers while keeping the primary interface as simple and flexible as possible.

• 6.1.1 Full versus partial compliance