The Plug and Play Architecture: A Brief History

< BACK  NEXT >

[oR]

It is apparent that the revolution of the PC within the industry occurred because everyone could afford and use computers. Yet more than a decade went by during which naive users were expected to understand the hardware details of each device inserted into their systems. Knowledge of I/O port, interrupt level, and DMA channel usage of every existing device within a system was prerequisite when installing a new device.

Further, the design of operating systems assumed a very static hardware configuration. The installation or removal of a device required, at a minimum, a full reboot of the OS.

With the advent of Windows 95 (and some hardware prerequisites), a concerted effort to automate the configuration of new and removed devices was implemented. This attempt greatly enhanced the acceptance of and migration to Windows 95, which in turn accelerated the migration to 32-bit OS PC environments such as NT. With Windows 2000, Microsoft has enhanced and implemented a complete Plug and Play architecture for the I/O subsystem.

Goals of Plug and Play

The overall goal of the Plug and Play (PnP) architecture is to provide automated support for the installation and removal of system devices. To support this overall goal, several features are necessary.

• Automatic detection of installed and removed hardware. The device and the bus in which it inserts must notify controlling software that a particular device configuration has changed.

• Devices must allow for software configuration. The port, IRQ, and DMA resources used by a device must be capable of assignment by controlling software. (In other words, configuration of a board can no longer come from DIP switches or jumpers.)

• Necessary drivers for new hardware must be automatically loaded as needed by the operating system.

• When devices and their interfacing buses permit, the system should support hot plugging of the device. That is, it should be possible to insert or remove the device into or from a "live" system without disturbing operation.

While necessary, these goals are aggressive and invasive, and they require support from all levels of hardware and software.

Components of Plug and Play

The Windows 2000 operating system implements PnP with numerous software components. These components are depicted in Figure 9.1.

Figure 9.1. PnP components.

PLUG AND PLAY MANAGER

The PnP Manager consists of two parts, kernel-mode and user-mode. The kernel-mode part interacts with hardware and other kernel-mode components to manage proper detection and configuration of hardware. The user-mode part interacts with user interface components to allow inter- active programs to query and alter the configuration of installed PnP software.

POWER MANAGER

The Power Manager facilitates the management of power to devices. Depending upon its nature, it may be possible to temporarily remove power from a device that is not being used over a prolonged period of time. This component recognizes and routes power events to appropriate drivers.

REGISTRY

The Windows 2000 Registry maintains a database of installed hardware and software of PnP devices. The contents of the Registry assist drivers and other components in identifying and locating the resources used by a device.

INF FILES

Each device must be fully described by a file used during installation of the controlling driver. Each device/driver combination must supply a properly formatted INF file.

PLUG AND PLAY DRIVERS

Drivers for PnP devices fall into two categories, WDM and NT drivers. NT PnP drivers are legacy drivers that rely upon some aspects of the PnP architecture but do not otherwise fully conform to the WDM model. For example, they might rely upon the services of the PnP Manager to obtain configuration information, but do respond to PnP IRP messages. WDM drivers are, by definition, fully PnP compliant.

< BACK  NEXT >