A DeviceDriver is a piece of code which is used by the operating system to help communicate with a piece of hardware on a machine.

In the past, Drivers have been specialized, hyper-optimized code fragments interpreted in a very particular manner for a specific OS.

DeviceDrivers were probably the first step OSs made to becoming modular - the devices on a system are no longer hard-coded into the kernel, but instead are loaded dynamically at startup, depending on what devices are found on the local machines.

Current OSs need to support dynamic linking of devices _on the fly_, especially as USB becomes more and more of a standard. These HotSwappableDevices seem to cause a major headache on OSs built upon a traditional hierarchy.

There is a movement to try to unify the way drivers are made for the Intel architecture, called UDI (its homepage is at http://www.project-udi.org ). However, this requires NATIVE CODE SUPPORT for an OS. It has advantages in that drivers in UDI for Windows are supported across the board by any other OS which supports UDI. Since it is native code, support should be fast (albeit fragile). We don't need to support it, but it would be a nice feature. A major disadvantage is its lack of support for non-Intel machines (currently, at least).

DeviceDrivers are a classic OS design fundamental. They have been around for years, and probably won't go away. However, the traditional view of drivers is becoming antiquated. There is probably a better way to view a hardware device than the traditional driver. Since we are working with a built-from-the-ground-up OS with almost-pure OO support, we have a golden opportunity to discover and experiment with new ideas.

See also: [ DeviceArchitecture ] [ PlatformAPIPages ]

-- MattAlbrecht - 17 Nov 1999

Comments

Please feel free to make comments, and correct any grammar and spelling mistakes.

Content of these pages are owned and copyrighted by the poster.
Hosted by: