In computing, device drivers are computer programs that operate or control certain types of devices that are attached to a computer. A driver provides a software interface for hardware, enables the operating system and other computer programs to access hardware functions without needing to know the exact details about the hardware used.
A driver communicates with the device via a computer bus or communications subsystem that connects the hardware. When a calling program calls a routine in the driver, the driver issues a command to the device. After the device sends data back to the driver, the driver can call the routine in the original calling program. Drivers depend on specific hardware and operating systems. They usually provide the necessary interrupt handling for each asynchronous hardware-dependent hardware interface as needed.
Video Device driver
Destination
The main purpose of device drivers is to provide abstraction by acting as a translator between the hardware and the applications or operating systems that use them. Programmers can write higher-level application code independently of any specific hardware that end-users use.
For example, high-level applications to interact with serial ports may only have two functions to "send data" and "receive data". At a lower level, device drivers that implement these functions will communicate with certain serial port controllers installed on the user's computer. The command required to control the 16550 UART is much different from the command required to control the FTDI port serial port, but any hardware-specific device drivers describe these details into the same (or similar) software interface.
Maps Device driver
Development
Writing device drivers requires an in-depth understanding of how hardware and software work for specific platform functions. Because drivers require low-level access to hardware functions to operate, drivers typically operate in very special environments and can cause system operational problems if things go wrong. In contrast, most user-level software on modern operating systems can be stopped without affecting other systems. Even drivers that execute in user mode can damage the system if the device is programmed incorrectly. These factors make it more difficult and dangerous to diagnose the problem.
The task of writing drivers thus usually falls to software engineers or computer engineers who work for hardware development firms. This is because they have better information than most outsiders about their hardware design. In addition, it is traditionally considered in the interests of hardware manufacturers to ensure that their clients can use their hardware optimally. 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 many device drivers, especially for use with open source and free operating systems. In such cases, it is important for hardware manufacturers to provide information about how devices communicate. Although this information can be learned by reverse engineering, it is much more difficult with hardware than with software.
Microsoft has tried to reduce system instability due to poorly written device drivers by creating a new framework for driver development, called Windows Driver Foundation (WDF). These include User-Mode Driver Framework (UMDF) that encourages the development of certain types of drivers - especially those that implement message-based protocols to communicate with their devices - as user-mode drivers. If driver damage is like that, they do not cause system instability. The Kernel-Mode Driver Framework (KMDF) model continues to enable the development of kernel-mode device drivers, but tries to provide standard implementation of functions 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 a macOS called I/O. Kit.
In a Linux environment, programmers can build device drivers as part of the kernel, separately as loadable modules, or as user-mode drivers (for specific device types where kernel interfaces exist, such as for USB devices). Makedev includes a list of devices on Linux: ttyS (terminal), lp (parallel port), hd (disk), loop, sound (this includes mixer, sequencer, dsp, and audio)...
The Microsoft Windows.sys and Linux.ko modules contain device drivers that can be loaded. The advantage of loadable device drivers is that they can be loaded only when needed and then unloaded, thus storing kernel memory.
kernel vs. mode user mode
Device drivers, especially on modern Microsoft Windows platforms, can run in kernel-mode (Ring 0 on x86 CPU) or in user mode (Ring 3 on x86 CPU). The main benefit of running drivers in user mode is improving stability, since poorly written user mode device drivers can not damage the system by overwrapping the kernel's memory. On the other hand, user/kernel-mode transitions usually impose considerable performance overheads, thus prohibiting user mode drivers for low latency and high throughput requirements.
The kernel space is accessible to the user module only through the use of system calls. End user programs such as UNIX shell or other GUI-based applications are part of the user space. This app interacts with hardware through kernel supported functions.
Apps
Due to the diversity of modern hardware and operating systems, drivers operate in many different environments. Drivers can interact with:
- Printer
- Video adapter
- Network card
- Sound card
- Local bus of various types - in particular, to master buses on modern systems
- Low bandwidth I/O bus of various types (for pointing devices like mouse, keyboard, USB, etc.)
- Computer storage devices such as hard disks, CD-ROMs, and floppy disk buses (ATA, SATA, SCSI)
- Apply support for various file systems
- Image scanner
- Digital camera
The abstraction levels common to device drivers include:
- For hardware:
- Live interface
- Write or read from the device control list
- Uses some higher level interface (eg Video BIOS)
- Use other lower level device drivers (e.g., file system drivers using disk drivers)
- Simulates work with hardware, while doing something completely different
- For software:
- Allows direct operating system access to hardware resources
- Only apply primitives
- Implement the interface for non-driver software (eg TWAIN)
- Apply language, sometimes quite high-level (eg PostScript)
So choosing and installing the correct device drivers for the given hardware is often a key component of the computer system configuration.
Virtual device drivers
The virtual device driver represents a specific variant of the device driver. They are used to replicate hardware, especially in a virtualized environment, for example when a DOS program is run on a Microsoft Windows computer or when a guest operating system is run, for example, a Xen host. Instead of enabling guest operating systems to dialogue with hardware, virtual device drivers take the opposite role and emulate the hardware part, so that guest operating systems and drivers running inside virtual machines can have the illusion of accessing real hardware. Attempts by the guest operating system to access the hardware are directed to the virtual device driver in the host operating system as for example, the call function. Virtual device drivers can also send processor-level event simulations like interrupts to virtual machines.
Virtual devices can also operate in non-virtualized environments. 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 is Daemon Tools.
There are several variants of virtual device drivers, such as VxD, VLM, and VDD.
Open the
driver- Printer: CUPS
- RAID: CCISS (Compaq Command Interface for SCSI-3 Support)
- Scanner: SANE
- Video: Vidix, Direct Rendering Infrastructure
Solaris description of commonly used device drivers:
- fas: SCSI control fast/wide
- hme: Fast (10/100 Mbit/s) Ethernet
- isp: differential SCSI controller and SunSwift card
- glm: (Gigabitud Link Module) UltraSCSI Controller
- scsi: Small Serial Computer Interface (SCSI) Device
- sf: soc or social Fiber Channel Arbitrated Loop (FCAL)
- soc: SPARC Storage Array (SSA) controllers and control devices
- social: serial optical controller for FCAL (soc)
API
- Windows Display Driver Model (WDDM) - graphical display driver architecture for Windows Vista, Windows 7, Windows 8, and Windows 10.
- Unified Audio Model (UAM)
- Windows Driver Foundation (WDF)
- Windows Driver Model (WDM)
- Network Drive Interface Specification (NDIS) - a standard network card driver API
- Advanced Linux Sound Architecture (ALSA) - in 2009 the default Linux voice-driver interface
- Easy Access Scanner Now (SANE) - public domain interface for raster-image scanner-hardware
- I/O Kit - Apple's open source framework for developing macOS device drivers
- Installable File System (IFS) - an API filesystem for IBM OS/2 and Microsoft Windows NT
- Open Data Interface Interface (ODI) - a network card API similar to NDIS
- Uniform Driver Interface (UDI) - interconnection drive interfaces project
- Dynax Driver Framework (dxd) - C open source cross-platform driver framework for KMDF and IOKit
Identifier
Devices on a PCI or USB bus are identified by two IDs, each of which consists of 4 hexadecimal numbers. The vendor ID identifies the device vendor. The device ID identifies specific devices from the manufacturer/vendor.
PCI devices often have ID pairs for the device's main chip, as well as a pair of subsystem IDs that identify vendors, which may differ from chip manufacturers.
See also
References
External links
- Windows Hardware Developer Center
- Linux Hardware Compatibility List and Linux Driver
- Understanding Modern Device Drivers (Linux)
- BinaryDriverHowto, Ubuntu.
- Linux Driver Source
Source of the article : Wikipedia
0 Comments