Requirements for the Generic Bus Driver Model Microsoft Corporation December 1998 This article is intended for hardware device designers for all operating systems, not just the Microsoft® Windows® 98 and Windows 2000 operating systems. It describes a generic model for device enumeration that can be performed by any operating system to discover and enable the hardware devices it finds on a platform. This generic model imposes design requirements for hardware devices that run on the platform: devices must be discoverable, self-describing, and multiplexable. Universal Serial Bus (USB) devices are examined in this article to determine how well they correspond to this generic model and meet these device design requirements. However, these ideas are not specific to USB; they can be applied to other buses. In general, all operating system designers strive to meet these goals: • Provide an enhanced user experience. An operating system is successful from the users' point of view if the system is easy to use and easy to upgrade. • Enable multiple devices from multiple Independent Hardware Vendors (IHVs) to run transparently. An operating system is successful from the hardware vendors' point of view if the operating system treats equally all devices running on the platform. The operating system must allow a device to run on a platform regardless of the device class, device manufacturer, and presence or absence of any other particular device on the platform. • Facilitate development of IHVs software. Ideally, IHVs would not have to write a device driver for their device to run on the platform. If a driver is required, it should consist of a small amount of code with the simplest logic possible. This article describes two types of operating systems, arbitrarily called "Type 1" and "Type 2," and compares how well they meet the three goals in relation to hardware configuration. How a Type 1 Operating System Searches for Hardware Devices A Type 1 operating system loads drivers on speculation and expects the driver code to search for its own hardware. The loaded driver searches for its hardware using a device-specific method that typically touches all the devices already installed on the platform. Problems with this method are: • Detection methods used by drivers might conflict with hardware already installed on the platform. For example, if a platform has a drill press installed, the detection method used by a newly installed driver could inadvertently start up the drill press, causing material damage. • Detection methods can inadvertently detect a device other than the one the loaded driver controls. • This method requires the operating system to load all possible drivers. • When loaded, the driver must assume its hardware is present; however, drivers are loaded whose hardware is not present. • Hot plugging and unplugging of devices is not quick or easy. This list shows that a Type 1 operating system does not promote the two higher priority operating system design goals: enhanced user experience and interoperability of devices. A Type 1 operating system might promote the lowest priority goal: it can be easier for IHVs to write drivers for their devices because the driver logic assumes the IHV's device is present whenever the driver is invoked, and the driver simply begins using a device. However, this simplifying assumption can lead to some of the problems listed that do not promote the higher priority goals of a good user experience and interoperability of devices. How a Type 2 Operating System Searches for Hardware Devices A Type 2 (Plug and Play) operating system uses components called "bus drivers" each time the system boots to discover and enable the hardware devices currently installed on the platform. If the bus supports it, bus drivers can also handle hot plugging and hot unplugging of devices between boot events. A Type 2 operating system promotes the higher priority operating system design goals. • The user experience is enhanced because the operating system automatically adjusts to hardware configuration changes and can easily handle hot swapping of devices. • Interoperability of devices on the bus is promoted because functions on the bus can come from multiple IHVs and generic extensions are possible at any time. Generic Bus Driver Model Each bus driver sees its bus in a simple, general way: some number of "functions" is currently attached to the bus, which the bus driver owns. All functions look alike to a bus driver. See Figure 1. Figure 1. Generic bus driver model In this model, the bus driver discovers hardware functions first, then loads drivers only as they are needed. The bus driver can even prompt the user when it discovers a device and finds no driver is installed for that device. To keep it simple, the bus driver maps each function to one driver (there is a one-to-one mapping of a hardware function to a loaded device driver). To select the driver to load, the bus driver requires no device-specific information and no information about what other functions are currently attached to the bus. The generic bus driver that enables a Type 2 operating system has the following characteristics: • A bus driver sees its bus in a simple, general way. For a bus driver, there are no device class dependencies. The membership of an attached function in one device class or another (for example, storage, audio, input, and so on) is transparent to the bus driver. • A bus driver discovers all functions using the same method. Specifically, and most importantly, the bus driver requires no knowledge of what functions are already on the bus, or their state, to discover another function. A simple example of this is shown in Figure 2, where functions "X" and "Y" are shown enclosed in one hardware device container; however, the bus driver does not need to know anything about "X" to discover "Y" and vice versa. • A bus driver creates an abstraction (in the form of a data structure) for each function it discovers. The driver that the bus driver loads to control the discovered function uses this abstraction to access its function. • A bus driver does not load a driver for a function not currently attached to the bus. Figure 2. Generic bus driver model when two functions are contained in one device Bus Driver and Device Requirements for a Generic Driver Model Bus driver code does the following: • Discovers ("enumerates") all functions on the bus. • Determines the capabilities of each function. For example, what resources, such as I/O ports, memory ranges, IRQ ranges, power, and/or bandwidth, can the function use? What driver(s) can control the device? • Loads a driver for each function it discovers. • Gives each function a unique structure or handle (provides an abstraction that allows the loaded driver to access its function). For a device, or function, to participate in the generic bus driver model, it must be: • Discoverable - When the function is attached to the bus, it can be found by the bus driver. • Self-describing - The function must describe itself to the bus driver so the bus driver can find a driver to load. • Multiplexable - Each function must be individually controllable with no cross- dependencies between functions (access to one function does not require knowledge of another function's state or access to another function). Applying the Requirements to USB Devices and Interfaces Some USB device designs fit the generic bus driver model by meeting the requirements of discoverability, self-description, and multiplexability. Other USB device designs do not fit the model, with consequences described in the following section. Note USB hardware functions are described either at the device level (in the device descriptor) or at the interface level (in an interface descriptor). Simple USB devices meet all three requirements for participating in the generic bus driver model: • Discoverable - Each device plugs into one USB port. • Self-describing - The device descriptor in ROM describes the device. • Multiplexable - Each device has a unique USB address. Most USB devices can be further enumerated by functional interface, beyond the simple device itself. USB devices of this type may not meet the requirements of discoverability and multiplexability. • Discoverable - If special information is required in descriptors to group interfaces into functions, this is a problem for a generic bus driver. • Self-describing - The interface descriptor in ROM describes the function to a generic bus driver, so there is no problem. • Multiplexable - If a function cannot be controlled independently of other functions, this is a problem for a generic bus driver. Examples of Problems with Some USB Devices The USB Audio class specification requires multiple, interacting interfaces to perform a single function. This means the USB bus driver must "discover the function" by lumping together some predetermined set of interfaces, requiring Audio class-specific information in the descriptors and Audio class-specific (special-case) code in the USB bus driver. This special-case code means that not every function looks the same to the USB bus driver. The USB Communications class specification requires two interacting interfaces to perform the single function of "legacy modem." The USB bus driver must contain code that uses Communications class-specific information in the device descriptor to recognize yet another special case. (See http://www.usb.org/developers/ to obtain current versions of USB Class Definition for Communications Devices, USB Device Class Definition for Audio Devices, and USB Specification.) Current USB bus driver code must contain blocks of special-case code for two class- specific exceptions to the generic model for device enumeration: one for the Audio class and one for the Communications class. This increases the complexity of the code, and fully testing the code is more difficult. This has a potential negative impact on the end users' experience with USB devices and the interoperability of USB functions on a platform. An objective at Microsoft is to add no more special-case code to the Windows USB bus driver. Call to Action for Designers of Future USB Devices: Designers of future USB devices are strongly encouraged to use one of the following design alternatives, so the device fits the generic bus driver model required by the USB bus driver. • Build one USB device that has one function. • Build one USB device that has multiple, independently operating functions with a one-to-one mapping of device functions to USB interfaces. By using one of these two alternatives, the IHV does not have to write a driver to do class-specific enumeration, and new classes will not need new enumerators. Note When a USB device designer does not use one of these design alternatives, an additional driver that does the class-specific device enumeration must be provided. In the beginning, this driver must be written by the IHV but might eventually be provided by the operating system vendor. Call to Action for Device Designers of Future Devices on Other Buses: • Buses other than USB, including new buses in the future, have bus drivers that use the generic device enumeration model presented in this article. • Designers of devices for these buses must understand what the generic bus driver model means for a device on that bus and strive to design devices that are discoverable, self-describing, and multiplexable. Send feedback to MSDN. Look here for MSDN Online resources. . alike to a bus driver. See Figure 1. Figure 1. Generic bus driver model In this model, the bus driver discovers hardware functions first, then loads drivers. load, the bus driver requires no device-specific information and no information about what other functions are currently attached to the bus. The generic bus