Writing a device driver requires an in-depth understanding of how the hardware and the software work for a given
platform function. Because drivers require low-level access to hardware functions in order to operate, drivers typically operate in a highly
privileged environment and can cause system operational issues if something goes wrong. In contrast, misbehavior in most user-level software on modern operating systems can be stopped without greatly affecting the rest of the system. Even drivers executing in
user mode can crash a system if the device is
erroneously programmed. These factors make it more difficult and dangerous to diagnose problems. The task of writing drivers thus usually falls to
software or
computer engineers who work for hardware-development companies. This is because, as employees, they have better information than most outsiders about the design of the hardware. Moreover, it was traditionally considered in the hardware
manufacturer's interest to guarantee that their clients can use their hardware in an optimal way. Typically, the
hardware abstraction portion of the driver is written by the operating system vendor, while the lower-level physical device access portion is implemented by the device vendor. However, in recent years, non-vendors have written numerous device drivers for proprietary devices, mainly for use with
free and open source operating systems. In such cases, it is important that the hardware manufacturer provide information on how the device communicates. Although this information can instead be learned by
reverse engineering, this is much more difficult with hardware than it is with software.
Windows uses a combination of driver and minidriver, where the full class/port driver is provided with the operating system, and miniclass/miniport drivers are developed by vendors and implement hardware- or function-specific subset of the full driver stack. Miniport model is used by
NDIS,
WDM,
WDDM,
WaveRT,
StorPort,
WIA, and
HID drivers; each of them uses device-specific APIs and still requires the developer to handle device management tasks.
Microsoft has attempted to reduce system instability due to poorly written device drivers by creating a new framework for driver development, called
Windows Driver Frameworks (WDF). This includes
User-Mode Driver Framework (UMDF) that encourages development of certain types of drivers—primarily those that implement a
message-based protocol for communicating with their devices—as user-mode drivers. If such drivers malfunction, they do not cause system instability. The
Kernel-Mode Driver Framework (KMDF) model continues to allow development of kernel-mode device drivers but attempts to provide standard implementations of functions that are known to cause problems, including cancellation of I/O operations, power management, and plug-and-play device support.
Apple has an open-source framework for developing drivers on
macOS, called I/O Kit. In Linux environments, programmers can build device drivers as parts of the
kernel, separately as loadable
modules, or as user-mode drivers for certain types of devices where kernel interfaces exist, such as for USB devices.
Makedev includes a list of the devices in Linux, including ttyS (terminal), lp (
parallel port), hd (disk), loop, and sound (these include
mixer,
sequencer,
dsp, and audio).
Microsoft Windows .sys files and
Linux .ko files can contain loadable device drivers. The advantage of loadable device drivers is that they can be loaded only when necessary and then unloaded, thus saving kernel memory. ==Privilege levels==