Requirements for the Generic Bus Driver Model

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 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.