Device Drivers

Definition In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device. A device driver simplifies programming by acting as translator between a hardware device and the applications or operating system that use it. Programmers can write the higher-level application code independently of whatever specific hardware device.

Why Do We Need Device Drivers? In the early days of computers, programmers wrote programs that worked directly at the hardware level. If the program needed to access information from an external piece of machinery such as a card reader for instance, the program had to deal directly with that card reader in a highly detailed way. The same program might not work with a different card reader, even when running on the same type of computer, meaning that the program would have to be rewritten. Obviously, this caused a lot of duplication of programming effort, resulting in higher cost software and non-portable programs.

Functions A device driver processes the request of an application and then sends the instruction to the hardware device to produce the output. This is how the display information is sent from the operating system to the display or monitor. A device driver typically has a configuration interface that can be accessed so that the user can make adjustments to the hardware device.

Design Device drivers can be abstracted into logical and physical layers. Logical layers process data for a class of devices such as Ethernet ports or disk drives. Physical layers communicate with specific device instances. For example, a serial ports needs to handle standard communication protocols such as XON/OFF that are common for all serial port hardware. This would be managed by a serial port logical layer. However, the physical layer needs to communicate with a particular serial port chip. 

The Structure Of A Device Driver A device driver by its nature has a very rigid structure. DOS must be able to work properly with any driver, so all drivers must follow an agreed upon design. Every driver is made up of three parts: the device header, the strategy routine, and the interrupt routine, and are everything that DOS needs to use the driver.

Development Writing a device driver requires an in-depth understanding of how the hardware and the software of a given platform function. Drivers operate in a highly privileged environment and can cause disaster if they get things 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.

Thus the task of writing drivers usually falls to software 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.

File Types A device driver can have a file type of DLL or EXE depending on what type or program is being used. Many software programs that communicate with a device use a combination of DLL and EXE files in order for the device to function properly. An example of this would be a TV Tuner card. Software needs to be installed to display the video on the screen or send audio to the speakers.

Kernel-mode vs user-mode Device drivers, particularly on modern Windows platforms, can run in kernel-mode0 (Ring ) or in user-mode (Ring 3).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. 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. Drivers may interface with: Printers Video adapters Network Cards Sound Cards  Devices such as Hard Disk, CD-ROM and Floppy Disk buses (ATA, SATA, SCSI) Image Scanners Digital Cameras etc

Installation A device driver is typically installed when the installation CD for a new hardware device is used to run the setup program. The installation CD contains the device drivers as well as any additional software applications that are needed to use the new hardware device. A device driver will stay on the system until it is removed or uninstalled

Updating Device drivers can be updated on a system using a variety of methods. Typically, a device driver can be downloaded from the manufacturer if an update is available. Many times a manufacturer will update a device driver to add additional functionality or to fix a bug in the program. A device driver can also be updated by installing updates to the operating system or running the setup program from a device's installation CD.

Conflicts Sometimes a device driver can conflict with other components on a system. The Device Manager in Windows can be used to see if there is any sort of conflict with an installed device. Conflicts can usually be resolved by repairing corrupt files or removing a device and attempting to reinstall it on the system.

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

Thank You

Bibliography Wikipedia www.ehow.com www.bbc.org www.ezine.com