8.2. Motivation
If you have ever installed a printer or a modem, you know that simply connecting them to a computer probably won't work. On many occasions you have to download and set up drivers, configure operating systems, and reboot the machine. Along the way you gain a lot of unwanted knowledge of buses, ports, speeds, connector genders, and interrupt request numbers when you really want to print documents or surf the Web. That's why plug-and-play is a great feature to have.
The following is probably a more pleasant experience. Suppose you want to get the pictures that you've taken out of a digital camera. You extract the flash RAM card, fit it into an adapter, and insert it into a laptop's PC Card slot. The computer beeps and a dialog pops up to say a new device has been detected. You find that the memory card appears as another icon of a hard drive, with which you can copy the images, just like you would with any regular disk drive. Once you are done, you eject the card, and the laptop acknowledges its removal. How painless!
What are some features that bring about such seamless operation? First, automatic detection of devices without interrupting operation. There is no need to reboot the system. Second, consistent representation of the device. The card appears as an icon, just like any other operable object in the desktop environment. Thus, a user will have no trouble figuring out how to interact with it. Third, abstraction. The memory card is certainly not a disk drive, but making it look and operate like one relieves a user from learning the details of a new type of device.
DA has been designed to achieve similar characteristics. When a device comes online, it is represented as a device service within the framework, just like the memory card was an icon on the desktop. For example, a ZIP drive connected to a parallel port can cause ParallelService to be registered.
As soon as a device service is found to have been registered, a device refinement process is attempted to provide a better abstraction (or refinement) for the new device service, just like the memory card is abstracted to a disk drive. The central character in device refinement is the device manager, which keeps a lookout for device service registrations. It involves driver services, which understand the particulars of certain types of devices and if better abstractions are available. To continue with our example, the device manager asks existing driver services to refine the newly registered ParallelService. One driver may know about the parallel port ZIP drive, so it responds positively and eventually is selected by the device manager to register another device service, ZipDiskService. Other drivers do not have the knowledge of this device setup. They may be able to handle a mouse attached to a USB port, a printer to a parallel port, or a ZIP drive to a SCSI interface, but not a ZIP drive to a parallel port. That is why they are queried, but are not chosen.
To reiterate, the device refinement process starts with the registration of a device service. It ends with the registration of another device service, which is considered a better abstraction of the previous one. The device manager moves the entire process along. It consults many driver services and selects the best driver. The selected driver then registers the refined device service.
There are, of course, more details to this, but as you read along, don't lose sight of the big picture.