Editing Device driver (section)

==Development==
Writing a device driver requires an in-depth understanding of how the hardware and the software works for a given [[Computing platform|platform]] function. Because drivers require low-level access to hardware functions in order to operate, drivers typically operate in a highly [[privilege (computing)|privilege]]d environment and can cause system operational issues if something goes wrong. In contrast, most user-level software on modern [[operating system]]s 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 [[Erroneous program|erroneously programmed]]. These factors make it more difficult and dangerous to diagnose problems.<ref>{{cite book|url=https://books.google.com/books?id=9aFQAAAAMAAJ&q=writing+a+device+driver|title=Writing device drivers: tutorial and reference|year=1995|author=Burke, Timothy|publisher=Digital Press|isbn=9781555581411|access-date=2016-08-05|archive-date=2021-01-26|archive-url=https://web.archive.org/web/20210126050637/https://books.google.com/books?id=9aFQAAAAMAAJ&q=writing+a+device+driver|url-status=live}}</ref>

The task of writing drivers thus usually falls to [[software engineer]]s or [[computer engineer]]s who work for hardware-development companies. This is because they have better information than most outsiders about the design of their 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 [[Logical Device Driver]] (LDD) is written by the operating system vendor, while the [[Physical Device Driver]] (PDD) 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 system]]s. 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.

[[Microsoft Windows|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.<ref>{{cite web |url=https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/choosing-a-driver-model |title=Choosing a driver model |publisher=Microsoft |access-date=2021-03-30}}</ref> Miniport model is used by [[Network Driver Interface Specification#Specification|NDIS]],  [[Windows Driver Model#Object-oriented driver stack|WDM]], [[Windows Display Driver Model|WDDM]], [[WaveRT]], [[StorPort]], [[Windows Image Acquisition|WIA]], and [[Human Interface Device|HID]] drivers; each of them uses device-specific APIs and still requires the developer to handle tedious 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 Inc.|Apple]] has an open-source framework for developing drivers on [[macOS]], called I/O Kit.

In [[Linux kernel|Linux]] environments, programmers can build device drivers as parts of the [[Linux kernel|kernel]], separately as loadable [[loadable kernel module|module]]s, 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 [[Sound card mixer|mixer]], [[Music sequencer|sequencer]], [[Digital signal processor|dsp]], and audio).<ref>{{cite web
 | url = http://linux.about.com/od/commands/l/blcmdl8_MAKEDEV.htm
 | title = MAKEDEV&nbsp;— Linux Command&nbsp;— Unix Command
 | publisher = Linux.about.com
 | date = 2009-09-11
 | access-date = 2009-09-17
 | archive-date = 2009-04-30
 | archive-url = https://web.archive.org/web/20090430115615/http://linux.about.com/od/commands/l/blcmdl8_MAKEDEV.htm
 | url-status = live
 }}</ref>

[[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.