Device driver

[1] Programmers can write higher-level application code independently of whatever specific hardware the end-user is using.

At a lower level, a device driver implementing these functions would communicate to the particular serial port controller installed on a user's computer.

Writing a device driver requires an in-depth understanding of how the hardware and the software works for a given platform function.

Even drivers executing in user mode can crash a system if the device is erroneously programmed.

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.

The advantage of loadable device drivers is that they can be loaded only when necessary and then unloaded, thus saving kernel memory.

Depending on the operating system, device drivers may be permitted to run at various different privilege levels.

The choice of which level of privilege the drivers are in is largely decided by the type of kernel an operating system uses.

By contrast, a system designed around microkernel, such as Minix, will place drivers as processes independent from the kernel but that use it for essential input-output functionalities and to pass messages between user programs and each other.

[5] On Windows NT, a system with a hybrid kernel, it is common for device drivers to run in either kernel-mode or user-mode.

On many systems, such as those with x86 and ARM processors, switching between rings imposes a performance penalty, a factor that operating system developers and embedded software engineers consider when creating drivers for devices which are preferred to be run with low latency, such as network interface cards.

Computers often have many diverse and customized device drivers running in their operating system (OS) kernel which often contain various bugs and vulnerabilities, making them a target for exploits.

These two aspects are usually not clearly distinguished, and the adoption of this distinction in the kernel design leads to the rejection of a hierarchical structure for protection.