Up to this point we have used the term ``device driver set'' fairly loosely; however, in the context of the OSKit device driver framework, this term has a very important, specific meaning. A driver set is a set of related device drivers that work together and are fairly tightly integrated together. Different driver sets running in a given environment are independent of each other and oblivious to each other's presence. Drivers within a set may share code and data structures internally in arbitrary ways; however, code in different driver sets may not directly share data structures. (Different driver sets may share code, but only if that code is ``pure'' or operates on a disjoint set of data structures: for example, driver sets may share simple functions such as memcpy.)
Of course, the surrounding OS can maintain shared data structures in whatever way it chooses; this is the only way drivers in different sets can interact with each other. For example, if a kernel is using a FreeBSD device driver to drive one network card and a Linux driver to drive another, then the kernel can take IP packets coming in on one card and route them out through the other card, but the network device drivers themselves are completely oblivious to each other's presence.
Some driver sets may contain only a single driver; this is ideal for modularity purposes, since in this case each such driver is independent of all others. Also, given some effort on the part of the OS, some multi-driver sets can be ``split up'' into multiple single-driver sets and used independently; Section 6.4.1 describes one way this can be done.
In essence, each driver set represents an ``encapsulated environment'' with a well-defined interface and a clearly-bounded set of state. The concept of a driver set has important implications throughout the device driver framework, especially in terms of execution environment and synchronization; the following sections describe these aspects of the framework in more detail.
Note that currently all ``osenv'' code in the same address space is essentially a single driver set. We are planning on changing this to allow drivers to be independant from each other. Currently, the only way to achieve this is to run them in separate address spaces.