In my lab, it’s always device-driver hell—I don’t have two systems that are identical. This is quite different from most corporate environments but typical of most homes. Multiple device drivers are a headache to maintain, and they cause other problems as well.
I have one machine that has a problem booting Windows properly. The problem occurs well into the boot process, and it’s obviously related to the device drivers. I don’t have a clue which one, but it’s a problem of diagnosing Windows rather than a problem with Windows itself. Or is it?
Universal device drivers are not a new concept, but in practice they are rare. Some defacto universal drivers exist because the hardware has been locked-down. VGA (video graphics array), IDE (integrated development environment), and many USB (universal serial bus) device drivers come to mind. These standard drivers work on a wide range of systems because of hardware compatibility. They may not take advantage of all the hardware’s features, but they work. Hardware vendors often have their own drivers that provide higher performance or access to non-standard extensions.
I was recently talking with some designers of storage adapters. Their response about delivering a universal device driver was interesting. They justified vendor-specific drivers as being necessary to take advantage of cutting-edge hardware. This seems reasonable, however, it’s these very same vendors that have also been noted for their “unified” drivers to support their full range of hardware.
In truth, slight differences exist between each vendor’s drivers, but the bulk of their hardware and driver support is identical. Obviously, the drivers must conform to the operating system they support as well, so eventually at some level all devices look alike from an application standpoint.
There are two ways to get to a “unified” driver. One is to make different hardware look identical to the driver. The other is to parameterize the driver so supporting new hardware is simply a matter of adding a table. The idea is to minimize any customization so new hardware can be delivered faster. It also means that more operating systems could be targeted more quickly.
The idea of simplifying device-driver creation has been around for ages. Just look at the vast number of different device-driver models for Windows, and you get some indication of how tough the problem is. Still, moving in the direction of universality has many advantages, and the need for it is growing.
For me, the benefits of system debugging and diagnostics come to mind immediately, given my latest trouble with booting Windows and similar problems with things like Bluetooth devices. Programmers creating device drivers have no framework to support a debugging capability, plus they usually have just enough project time to get the drivers working for a select set of configurations. A common framework would allow diagnostic hooks to be in place for all drivers, including such status information as whether an application was waiting on a device or an interrupt.
Other benefits are enhanced security and improved reliability. Right now these features are mostly placed in the hands of the individual device-driver programmer who must follow certain guidelines. This means each driver will have a slightly different level of support or maybe none at all. The advantage of having common support in these areas is that any changes or bug fixes would ripple through all drivers in a system.
Certainly, virtualization is gaining support, as epitomized by today’s hardware enhancements in processors and IO support frameworks that allow device drivers direct access to the hardware. But this is bringing more complex system designs to maintain the current device-driver architecture. While a common device-driver model would not necessarily mean lower system complexity, it would greatly simplify operating system support if the devices were fully virtual.
So here’s to dreaming about a common device-driver standard.