Linux Device Drivers

This article is about my work and learning on Linux device drivers. In this article i’ll explain what is driver, why it’s needed, Linux driver types, generic driver architecture.

Device Drivers?

Device Driver is computer program that ‘operates’ or controls’ particular device attached to computer. 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 of the hardware being used. Drivers are hardware-dependent and operating-system-specific.

In single word “ABSTRACTS” hardware feature to OS.

Purpose of Device Drivers

Device drivers simplify programming by acting as translator between a hardware device and the applications or operating systems that use it. 

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

Roles of Device Drivers

• To initialize and configure the device.
• To perform standard I/O operations.
• To handle normal interrupt and system interrupt requests.
• Resetting and re-initializing the device.
• To unload the driver module.

This figure shows the place of device driver in computer systems. Device Driver is the program that connects computer software to hardware so it’s very critical component so normally it is divided into two parts, privileged (to secure hardware normally called Kernel Mode Driver) and non-privileged (User Mode Driver). In Linux OS User Application Interacts all I/O operations using device file and Driver’s kernel mode code interact with hardware and get data to and from device file.

In layman’s term lets assume user have one application that read keyboard key and display that letter on screen.

1. User press key and Application will read this key 

So user will hit key on keyboard -> keyboard’s controller will translate that key stroke into data and will put it on data bus -> Kernel Mode Driver will get this data and process (valid and security and more) -> This data will be written to device file -> User Application will have access to this file and it will read so at this stage user application can read this file and it can read the hardware key.

2. Application sends data to display on screen

User Application writes data to display device file -> KMD reads this files and checks validity and 

Types of Linux Device Drivers

Any Linux Device Driver can be classified into one of the 3 parts as shown below:

Char Drivers

Below Points shows some characteristics of char type drivers and how they are differentiated. 

• Writing/Reading character by character to/from device

• It is most common of all drivers 

• Operates in blocking mode because it wait for operation

• Synchronous with operation

• Deal with IO on a character by character basis.

• The most obvious example are  keyboard and mouse.

• Every motion or button click sends a character to the /dev/input/mouse0 device.

• Char devices are for communication devices, aren’t cached and can’t be mounted.

• If a user use a char file for writing data no other user can use same char file to write data which blocks access to other user

Block Drivers

Some of the distinguishable property of block drivers compared to char are listed as below.

• Writing/Reading block by block to/from device

• Operation takes long time and CPU intensive

• Asynchronous operation

• It read data in larger chunks or blocks. Data storage devices, such as  IDE hard drives (/dev/hd), SCSI hard drives (/dev/sd), and CD-ROMs (/dev/cdrom or /dev/sr0) are block devices.

• IO interactions with block devices transact with chunks of data (blocks), which allows large quantities of data to be moved back and forth more efficiently.

• Block devices can be mounted and are cached.

• Block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface.

• Unix systems, a block device can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length.

Generic Driver Architecture 

Normally one hardware device is being used across different OS and HW platforms and sometimes same device have different variants available with slight modifications, so we needed some standard architecture that prevents duplication for driver development. This Driver Architecture is also known as Device object model.  

OS/Platform Dependent Layer

• This layer code is responsible for providing the platform and OS specific interface to the driver and this layer is fully integrated with the host platform and OS and as such it has full access to any services provided by the OS.

• This layer must be replicated on each OS which supports this driver. 

• Separate platforms running the same OS may be able to reuse significant portions if not all of this layer. 

OS/Platform Independent Layer

• This layer code is responsible for implementing low level hardware access routines used to read and write device registers, collect statistics, maintain control structures and so on.

• At this layer, a limited set of data types and APIs are used because Keeping this layer relatively lightweight makes it easier to reuse code at this layer across multiple platforms and operating systems. 

• Although this layer is shown as logically separate from the OS, it will in fact be compiled into the OS which runs on the host platform.

Drivers which adopt this model are structured such that the majority of the code resides in the OS/Platform independent layer.  This approach maximizes the amount of code that can be reused.

The low level “Dev Object” layer can be further sub-divided into three components:

   1. Base Device Objects

• The base device object defines standard high level functions which apply to all devices.

• Functions are device creation, destruction, initialization, interrupt enabling and disabling, interrupt handler, generic information display, etc.

• Since this base object is present and standardized for every device, it can be invoked from common code which is entirely independent and unaware of the specific device type.

• The base object also defines a common base device data structure that contains standard debugging flags and other fields which are standardized across all devices.

• Base Device Object have only high level APIs and that also Device Independent.

2. Common Device Class Extensions

• Device Class specify the API for controlling a particular type of device.

• The device class defines an interface (APIs, control structures, etc.) used to configure, collect statistics, and monitor a given type of device.

• The device class typically provides a super-set of functionality required for supporting any particular device of a given type.

• In other words, it is not limited to operating any particular vendor’s implementation of the device.

• A well designed of device class provide an interface that is reusable on any vendor’s implementation of a given device type. Since the device class is defined within Device Object scope, it allows that interface to be fully reused on other operating systems and hardware platforms.

3. Device Specific Extensions

• Device Specific Extension Device specific extensions define an interface for invoking functions specific to a particular device or vendor part.

• Some vendor’s proprietary counters beyond those defined in the common class. 

• These vendor or device specific functions can be addressed in this class. 

• Use of device specific extensions is generally minimized since this approach is the least reusable. 

• These extensions do make sense for functions which are not applicable to the common device class.