Device driver

In computing, a device driver is a computer program that operates or controls a particular type of device that is attached to a computer.[1] A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details about the hardware being used.

A driver communicates with the device through the computer bus or communications subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.[2]

Purpose

The main purpose of device drivers is to provide abstraction by acting as a translator between a hardware device and the applications or operating systems that use it.[1] Programmers can write higher-level application code independently of whatever specific hardware the end-user is using. For example, a high-level application for interacting with a serial port may simply have two functions for "send data" and "receive data". At a lower level, a device driver implementing these functions would communicate to the particular serial port controller installed on a user's computer. The commands needed to control a 16550 UART are much different from the commands needed to control an FTDI serial port converter, but each hardware-specific device driver abstracts these details into the same (or similar) software interface.

Development

Writing a device driver requires an in-depth understanding of how the hardware and the software works 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, 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.[3]

The task of writing drivers thus usually falls to software engineers or computer engineers 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 optimum 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. But in recent years non-vendors have written numerous proprietary device drivers, mainly for use with free and open source operating systems. In such cases, it is important that the hardware manufacturer provides 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 has attempted to reduce system instability due to poorly written device drivers by creating a new framework for driver development, called Windows Driver Foundation (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 the 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: ttyS (terminal), lp (parallel port), hd (disk), loop, sound (these include mixer, sequencer, dsp, and audio)...[4]

The Microsoft Windows .sys files and Linux .ko modules 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.

Kernel mode vs. user mode

Device drivers, particularly on modern Microsoft Windows platforms, can run in kernel-mode (Ring 0 on x86 CPUs) or in user-mode (Ring 3 on x86 CPUs).[5] The primary benefit of running a driver in user mode is improved stability, since a poorly written user mode device driver cannot crash the system by overwriting kernel memory.[6] On the other hand, user/kernel-mode transitions usually impose a considerable performance overhead, thereby prohibiting user-mode drivers for low latency and high throughput requirements.

Kernel space can be accessed by user module only through the use of system calls. End user programs like the UNIX shell or other GUI-based applications are part of the user space. These applications interact with hardware through kernel supported functions.

Applications

Because of the diversity of modern hardware and operating systems, drivers operate in many different environments.[7] Drivers may interface with:

Common levels of abstraction for device drivers include:

  • For hardware:
    • Interfacing directly
    • Writing to or reading from a device control register
    • Using some higher-level interface (e.g. Video BIOS)
    • Using another lower-level device driver (e.g. file system drivers using disk drivers)
    • Simulating work with hardware, while doing something entirely different[8]
  • For software:
    • Allowing the operating system direct access to hardware resources
    • Implementing only primitives
    • Implementing an interface for non-driver software (e.g. TWAIN)
    • Implementing a language, sometimes quite high-level (e.g. PostScript)

So choosing and installing the correct device drivers for given hardware is often a key component of computer system configuration.[9]

Virtual device drivers

Virtual device drivers represent a particular variant of device drivers. They are used to emulate a hardware device, particularly in virtualization environments, for example when a DOS program is run on a Microsoft Windows computer or when a guest operating system is run on, for example, a Xen host. Instead of enabling the guest operating system to dialog with hardware, virtual device drivers take the opposite role and emulates a piece of hardware, so that the guest operating system and its drivers running inside a virtual machine can have the illusion of accessing real hardware. Attempts by the guest operating system to access the hardware are routed to the virtual device driver in the host operating system as e.g., function calls. The virtual device driver can also send simulated processor-level events like interrupts into the virtual machine.

Virtual devices may also operate in a non-virtualized environment. For example, a virtual network adapter is used with a virtual private network, while a virtual disk device is used with iSCSI. A good example for virtual device drivers can be Daemon Tools.

There are several variants of virtual device drivers, such as VxDs, VLMs, and VDDs.

Open source drivers

Solaris descriptions of commonly used device drivers:

  • fas: Fast/wide SCSI controller
  • hme: Fast (10/100 Mbit/s) Ethernet
  • isp: Differential SCSI controllers and the SunSwift card
  • glm: (Gigabaud Link Module[12]) UltraSCSI controllers
  • scsi: Small Computer Serial Interface (SCSI) devices
  • sf: soc+ or social Fiber Channel Arbitrated Loop (FCAL)
  • soc: SPARC Storage Array (SSA) controllers and the control device
  • social: Serial optical controllers for FCAL (soc+)

APIs

Identifiers

A device on the PCI bus or USB is identified by two IDs which consist of 4 hexadecimal numbers each. The vendor ID identifies the vendor of the device. The device ID identifies a specific device from that manufacturer/vendor.

A PCI device has often an ID pair for the main chip of the device, and also a subsystem ID pair which identifies the vendor, which may be different from the chip manufacturer.

See also

References

  1. ^ a b "What is a device driver?". WhatIs.com. TechTarget. Retrieved 19 March 2018.
  2. ^ EMC Education Services (2010). Information Storage and Management: Storing, Managing, and Protecting Digital Information. John Wiley & Sons.
  3. ^ Burke, Timothy (1995). Writing device drivers: tutorial and reference. Digital Press.
  4. ^ "MAKEDEV — Linux Command — Unix Command". Linux.about.com. 2009-09-11. Retrieved 2009-09-17.
  5. ^ "User-mode vs. Kernel-mode Drivers". Microsoft. 2003-03-01. Retrieved 2008-03-04.
  6. ^ "Introduction to the User-Mode Driver Framework (UMDF)". Microsoft. 2006-10-10. Retrieved 2008-03-04.
  7. ^ Deborah Morley (2009). Understanding Computers 2009: Today and Tomorrow. Cengage Learning.
  8. ^ Computer Peripherals and Interfaces. Technical Publications Pune. January 2008. pp. 5–8. ISBN 8184314744. Retrieved 2016-05-03.
  9. ^ "What are Device Drivers and why do we need them?". drivers.com. April 17, 2015. Retrieved March 19, 2018.
  10. ^ "CCISS". SourceForge. 2010. Retrieved 2010-08-11. Drivers for the HP (previously Compaq) Smart Array controllers which provide hardware RAID capability.
  11. ^ Russell, Steve; et al. (2003-10-21). "Abbreviations and acronyms". Server Consolidation with the IBM eserver xSeries 440 and VMware ESX Serve. IBM International Technical Support Organization. p. 207. ISBN 0-7384-2684-9. Retrieved 2011-08-14.
  12. ^ "US Patent 5969841 - Gigabaud link module with received power detect signal". PatentStorm LLC. Retrieved 2009-09-08. An improved Gigabaud Link Module (GLM) is provided for performing bi-directional data transfers between a host device and a serial transfer medium.
  13. ^ "Unified Audio Model (Windows CE 5.0)". msdn.microsoft.com. Retrieved 2016-09-19.
  14. ^ "dxd - dynax driver framework: Main Page". dxd.dynax.at. Retrieved 2016-09-19.

External links

AMD Radeon Rx 300 series

The Radeon R5/R7/R9 300 series is a series of Radeon graphics cards made by Advanced Micro Devices (AMD). All of the GPUs of the series are produced in 28 nm format and use the Graphics Core Next (GCN) micro-architecture.

The GPUs are based on the Fiji architecture. Some of the cards of the series include the flagship AMD Radeon R9 Fury X along with the Radeon R9 Fury and Radeon R9 Nano, which are the first GPUs to feature High Bandwidth Memory (HBM) technology which is faster and more power efficient than current GDDR5 memory. However, the remaining GPUs in the series are based on previous generation GPUs with revised power management and therefore only feature GDDR5 memory. The Radeon 300 series cards including the R9 390X were released on June 18, 2015. The flagship device, the Fury X, was released on June 24, 2015, with the dual-GPU variant, the Radeon Pro Duo, being released on April 26, 2016.

Device file

In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in MS-DOS, OS/2, and Microsoft Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

Device files usually provide simple interfaces to standard devices (such as printers and serial ports), but can also be used to access specific unique resources on those devices, such as disk partitions. Additionally, device files are useful for accessing system resources that have no connection with any actual device such as data sinks and random number generators.

There are two general kinds of device files in Unix-like operating systems, known as character special files and block special files. The difference between them lies in how much data is read and written by the operating system and hardware. These together can be called device special files in contrast to named pipes, which are not connected to a device but are not ordinary files either.

MS-DOS borrowed the concept of special files from Unix but renamed them devices. Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words, chosen for a degree of compatibility with CP/M.

In some Unix-like systems, most device files are managed as part of a virtual file system traditionally mounted at /dev, possibly associated with a controlling daemon, which monitors hardware addition and removal at run time, making corresponding changes to the device file system if that's not automatically done by the kernel, and possibly invoking scripts in system or user space to handle special device needs. The FreeBSD and DragonFly BSD implementations have named the virtual device file system devfs and the associated daemon devd. Linux primarily uses a user space implementation known as udev, but there are many variants. Darwin, and operating systems such as macOS based on it, have a purely kernel-based device file system.

In Unix systems which support chroot process isolation, such as Solaris Containers, typically each chroot environment needs its own /dev; these mount points will be visible on the host OS at various nodes in the global file system tree. By restricting the device nodes populated into chroot instances of /dev, hardware isolation can be enforced by the chroot environment (a program can not meddle with hardware that it can neither see nor name—an even stronger form of access control than Unix file system permissions).

MS-DOS managed hardware device contention (see TSR) by making each device file exclusive open. An application attempting to access a device already in use would discover itself unable to open the device file node. A variety of device driver semantics are implemented in Unix and Linux concerning concurrent access.

Driver Verifier

Driver Verifier is a tool included in Microsoft Windows that replaces the default operating system subroutines with ones that are specifically developed to catch device driver bugs. Once enabled, it monitors and stresses drivers to detect illegal function calls or actions that may be causing system corruption. It acts within the kernel mode and can target specific device drivers for continual checking or make driver verifier functionality multithreaded, so that several device drivers can be stressed at the same time. It can simulate certain conditions such as low memory, I/O verification, pool tracking, IRQL checking, deadlock detection, DMA checks, IRP logging, etc. The verifier works by forcing drivers to work with minimal resources, making potential errors that might happen only rarely in a working system manifest immediately. Typically fatal system errors are generated by the stressed drivers in the test environment, producing core dumps that can be analysed and debugged immediately; without stressing, intermittent faults would occur in the field, without proper troubleshooting facilities or personnel.

Driver Verifier (Verifier.exe) was first introduced as a command-line utility in Windows 2000; in Windows XP, it gained an easy-to-use graphical user interface, called Driver Verifier Manager, that makes it possible to enable a standard or custom set of settings to select which drivers to test and verify. Each new Windows version has since introduced several new, more stringent checks for testing and verifying drivers and detecting new classes of driver defects.

Driver Verifier is not normally used on machines used in productive work. It can cause undetected and relatively harmless errors in drivers to manifest, especially ones not digitally signed by Windows Hardware Quality Labs, causing blue screen fatal system errors. It also causes resource-starved drivers to underperform and slow general operation if the constraints imposed by Verifier are not reversed after debugging. Microsoft recommends against verifying all drivers at the same time.

Driver wrapper

A driver wrapper is a subroutine in a software library that functions as an adapter between an operating system and a driver, such as a device driver, that was not designed for that operating system. It can enable the use of devices for which no drivers for the particular operating system are available. In particular, as of 2010 Microsoft Windows is the dominant family of operating systems for IBM PC compatible computers, and many devices are supplied with drivers for Windows but not other operating systems.

Free and open-source graphics device driver

A free and open-source graphics device driver is a software stack which controls computer-graphics hardware and supports graphics-rendering application programming interfaces (APIs) and is released under a free and open-source software license. Graphics device drivers are written for specific hardware to work within a specific operating system kernel and to support a range of APIs used by applications to access the graphics hardware. They may also control output to the display if the display driver is part of the graphics hardware. Most free and open-source graphics device drivers are developed by the Mesa project. The driver is made up of a compiler, a rendering API, and software which manages access to the graphics hardware.

Drivers without freely (and legally) -available source code are commonly known as binary drivers. Binary drivers used in the context of operating systems that are prone to ongoing development and change (such as Linux) create problems for end users and package maintainers. These problems, which affect system stability, security and performance, are the main reason for the independent development of free and open-source drivers. When no technical documentation is available, an understanding of the underlying hardware is often gained by clean-room reverse engineering. Based on this understanding, device drivers may be written and legally published under any software license.

In rare cases, a manufacturer's driver source code is available on the Internet without a free license. This means that the code can be studied and altered for personal use, but the altered (and usually the original) source code cannot be freely distributed. Solutions to bugs in the driver cannot be easily shared in the form of modified versions of the driver. Therefore the utility of such drivers is significantly reduced comparison to free and open-source drivers.

I/O Kit

The I/O Kit (written as IOKit in source code and sometimes elsewhere) is an open-source framework in the XNU kernel that helps developers code device drivers for Apple's macOS and iOS operating systems. The I/O Kit framework evolved from NeXTSTEP's DriverKit, and shared no similarities with either Mac OS 9's device driver framework, or that of BSD.

The I/O Kit framework is implemented in a subset of C++ which omits features that Apple feels are unsafe for use in a multithreaded kernel (exceptions, multiple inheritance, templates, run-time type information). Embedded C++ was chosen partly because Apple believed developers would be more comfortable writing drivers in a more commonly used language than Objective-C, while still providing an object-oriented framework allowing device driver developers to focus on coding features specific to their hardware instead of reimplementing features common to any given device.In addition to providing common code for device drivers, this framework also provides power management, driver stacking, automatic configuration, and dynamic loading of drivers.

Ioctl

In computing, ioctl (an abbreviation of input/output control) is a system call for device-specific input/output operations and other operations which cannot be expressed by regular system calls. It takes a parameter specifying a request code; the effect of a call depends completely on the request code. Request codes are often device-specific. For instance, a CD-ROM device driver which can instruct a physical device to eject a disc would provide an ioctl request code to do that. Device-independent request codes are sometimes used to give userspace access to kernel functions which are only used by core system software or still under development.

The ioctl system call first appeared in Version 7 of Unix under that name. It is supported by most Unix and Unix-like systems, including Linux and Mac OS X, though the available request codes differ from system to system. Microsoft Windows provides a similar function, named "DeviceIoControl", in its Win32 API.

Nouveau (software)

nouveau () is a free and open-source graphics device driver for Nvidia video cards and the Tegra family of SoCs written by independent software engineers, with minor help from Nvidia employees.

The project's goal is to create an open source driver by reverse engineering Nvidia's proprietary Linux drivers. It is managed by the X.Org Foundation, hosted by freedesktop.org, and is distributed as part of Mesa 3D. The project was initially based on the 2D-only free and open-source "nv" driver, which Red Hat developer Matthew Garrett and others claim had been obfuscated. nouveau is licensed under the MIT License.

The name of the project comes from the French word nouveau, meaning new. It was suggested by the original author's IRC client's French autoreplace feature, which suggested the word "nouveau" when he typed "nv".

Proprietary device driver

A proprietary device driver is a closed-source device driver published only in binary code. In the context of free and open-source software, a closed-source device driver is referred to as a blob:39 or binary blob. The term usually refers to a closed-source kernel module loaded into the kernel of an open-source operating system, and is sometimes also applied to code running outside the kernel, such as system firmware images, microcode updates, or userland programs. The term blob was first used in database management systems to describe a collection of binary data stored as a single entity.

When computer hardware vendors provide complete technical documentation for their products, operating system developers are able to write hardware device drivers to be included in the operating system kernels. However, some vendors, such as Nvidia, do not provide complete documentation for some of their products and instead provide binary-only drivers. This practice is most common for accelerated graphics drivers, wireless networking devices, and hardware RAID controllers. Most notably, binary blobs are very uncommon for non-wireless network interface controllers, which can almost always be configured via standard utilities (like ifconfig) out of the box; Theo de Raadt of OpenBSD attributes this to the work done by a single FreeBSD developer.

Radeon

Radeon () is a brand of computer products, including graphics processing units, random-access memory, RAM disk software, and solid-state drives, produced by Radeon Technologies Group (formerly AMD Vision), a division of Advanced Micro Devices. The brand was launched in 2000 by ATI Technologies, which was acquired by AMD in 2006 for 5.4 billion USD.

Radeon HD 2000 series

The graphics processing unit (GPU) codenamed Radeon R600 is the foundation of the Radeon HD 2000 series and the FireGL 2007 series video cards developed by ATI Technologies. The HD 2000 cards competed with nVidia's GeForce 8 series.

Radeon HD 3000 Series

The graphics processing unit (GPU) codenamed the Radeon R600 is the foundation of the Radeon HD 2000/3000 series and the FireGL 2007 series video cards developed by ATI Technologies.

Radeon HD 4000 series

The Radeon R700 is the engineering codename for a graphics processing unit series developed by Advanced Micro Devices under the ATI brand name. The foundation chip, codenamed RV770, was announced and demonstrated on June 16, 2008 as part of the FireStream 9250 and Cinema 2.0 initiative launch media event, with official release of the Radeon HD 4800 series on June 25, 2008. Other variants include enthusiast-oriented RV790, mainstream product RV730, RV740 and entry-level RV710.

Its direct competition was nVidia's GeForce 200 series, which launched in the same month.

Radeon HD 5000 Series

The Evergreen series is a family of GPUs developed by Advanced Micro Devices for its Radeon line under the ATI brand name. It was employed in Radeon HD 5000 graphics card series and competed directly with Nvidia's GeForce 400 Series.

Self-relocation

In computer programming, a self-relocating program is a program that relocates its own address-dependent instructions and data when run, and is therefore capable of being loaded into memory at any address. In many cases, self-relocating code is also a form of self-modifying code.

User-Mode Driver Framework

User-Mode Driver Framework (UMDF) is a device-driver development platform first introduced with Microsoft's Windows Vista operating system, and is also available for Windows XP. It facilitates the creation of drivers for certain classes of devices.

VxD

VxD is the device driver model used in Microsoft Windows/386, the 386 enhanced mode of Windows 3.x, Windows 9x, and to some extent also by the Novell DOS 7, OpenDOS 7.01, and DR-DOS 7.02 (and higher) multitasker (TASKMGR). VxDs have access to the memory of the kernel and all running processes, as well as raw access to the hardware.

Windows Driver Model

In computing, the Windows Driver Model (WDM) – also known at one point as the Win32 Driver Model – is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1, as well as the Windows NT Driver Model.

X video extension

The X video extension, often abbreviated as XVideo or Xv, is a video output mechanism for the X Window System. The protocol was designed by David Carver; the specification for version 2 of the protocol was written in July 1991. It is mainly used today to resize video content in the video controller hardware in order to enlarge a given video or to watch it in full screen mode. Without XVideo, X would have to do this scaling on the main CPU. That requires a considerable amount of processing power, which could slow down or degrade the video stream; video controllers are specifically designed for this kind of computation, so can do it much more cheaply. Similarly, the X video extension can have the video controller perform color space conversions, and change the contrast, brightness, and hue of a displayed video stream.

In order for this to work, three things have to come together:

The video controller has to provide the required functions.

The device driver software for the video controller and the X display server program have to implement the XVideo interface.

The video playback software has to make use of this interface.Most modern video controllers provide the functions required for XVideo; this feature is known as hardware scaling and YUV acceleration or sometimes as 2D hardware acceleration. The XFree86 X display server has implemented XVideo since version 4.0.2. To check whether a given X display server supports XVideo, one can use the utility xdpyinfo. To check whether the video controller provides the required functions and whether the X device driver implements XVideo for any of them, one can use the xvinfo program.

Video playback programs that run under the X Window system, such as MPlayer, MythTV or xine, typically have an option to enable XVideo output. It is very advisable to switch on this option if the system GPU video-hardware and device drivers supports XVideo and more modern rendering systems such as OpenGL and VDPAU are unavailable – the speedup is very noticeable even on a fast CPU.

While the protocol itself has features for reading and writing of video streams from and to video adapters, in practice today only the functions XvPutImage and XvShmPutImage are used: the client program repeatedly prepares images and passes them on to the graphics hardware to be scaled, converted and displayed.

General
Kernel
Process management
Memory management and
resource protection
Storage access and
file systems
List
Miscellaneous concepts

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.