Linux Driver Devices. Why, When, Which, How?

Bertrand Mermet Sylvain Ract Linux Driver Devices. Why, When, Which, How? Since its creation in the early 1990 s Linux has been installed on millions of computers or embedded systems. These systems may have had a lot of very different devices however the Linux kernel has few different versions; it can adapt thanks to the driver devices. The Linux kernel use to be presented as a chunk of executable code responsible for different things. These things are often split in five categories; Process management, memory management, file systems, networking and device control. The process management is in charge of creating and killing the different processes that runs to do what the user want to do and of managing the interactions between them by dealing with handlers and organizing the access to the CPU(s). The memory management organizes the access to the memory by creating for example virtual addresses for the processes. The file systems creates a structure on the physical layer to deal with data through files. We will show later in this article that a lot of things in Linux can be treated like files. Networking is processed in its own way because network operations are not specific to a task. The packets are analyzed and redistributed the processes that need it. Finally the device control is by itself an entire part because a process may want to access to several devices in a small amount of time. Besides several processes may want to access the same device. These pieces of code are going to be the main subject of this article. Our global questions are going to be Why? When? Which? How? We are going to say first why and when should we use driver devices. Then we will give some examples of driver devices and some tips to make it. 1

Why and when should we use driver devices? We said in introduction that Linux driver devices are only pieces of executable code - and it is true, but it does not take off anything about their importance. They are a vital link between the hardware layer composed by the different pieces of metal of a system and the software layer composed by the sessions and the applications running on the operating system. The drivers not only make a link between these two layers; they act like an abstraction mask. It means that the same applications can run on a lot of different machines, using different devices and in the other way a lot of different applications can use the same devices. According to this scheme, one of the role of the driver is the following: When a driver receive several requests from processes to access to its device it will schedule them in order to make them access alternatively to its unique resource but as fast as possible. One of the automatic problem linked with multiple access to a resource is competition. As soon as two processes may want to access to the same resource, for example the same device, there will be competition. It has become a huge problematic since we are building systems with more and more processors. Mechanisms to prevent from it are to be implemented directly in the code of the drivers. It can also be a solution to deal with problems linked with hot plug. For example if drivers are unplugged while they are accessing memory. A well known mechanism to deal with the access of a protected resource is the semaphore structure. If it is use to prevent from multiple access to a unique resource it is called a MutEx (Mutual Exclusion). It is generally organized through a counter and two functions called P and V. If a process wants to enter a critical section it calls the function P. If the value of the counter is above zero, the counter is decremented and the process enter the critical section. If, at the contrary, the counter is under or equal to zero, the process waits until somebody frees the semaphore. When the process leaves the critical section it calls the function V that frees the semaphore by incrementing the counter. According to this scheme the counter of a MutEx is initialized to 1. An other lighter mechanism is the Spinlock. The resource is protected by a bit meaning available or not. If the bit is at available the process can take the resource. Otherwise it enters a loop while the resource is unavailable. The advantage is that is can be implemented for processes that can go sleeping for example handlers. But the test must be proceeded in an atomic instruction. 2

Kernel modules In order to allow the kernel to run with more privileges than user applications, modern CPUs can be run in different operating modes. Unix systems use two of these modes to divide the running code into two different spaces. The kernel is executed in the highest level (also called supervisor mode) where it has unlimited access to all resources. And applications run in the lowest level with restricted access to system resources. These two spaces are usually referred to as user space and kernel space. User space applications can communicate with the kernel through system calls that are with hardware interruptions the only two events able to transfer execution to kernel space. In some cases device drivers could be run in user space, but most of the time it needs to execute in kernel space. Indeed several features needed by device drivers cannot be used from user space. Interrupts are not accessible in user space. Kernel space has direct access to physical memory and I/O ports. And last but not least, this is the only way to create drivers for many devices including block devices and network interfaces. The most basic way to execute drivers in kernel mode would be to add the code inside the kernel tree and recompile it. Luckily, the Linux kernel has the very interesting feature to be able to add code to the Linux kernel while it is running. Such a piece of code is called a kernel module, a module is actually an object file that can be dynamically linked/unlinked to the running kernel with the insmod/rmmod programs. Kernel modules have a lot of advantages over writing code directly in the kernel. There is no need to recompile the whole kernel to add a new feature, it makes debug easier and allows to prevent a specific piece of code to be executed (for instance a device driver containing a bug). It also saves memory because modules are loaded only when they are actually used (there is no need to load a camera driver if the camera is not connected for example). Device drivers doesn t work in the same way than most applications. Instead of executing a flow of instruction in order to perform a specific task, they follow the paradigm of event based programming. When loaded, the driver initializes all what he will need and registers the functions that he will be able to do. All the time the driver is loaded, it serves the requests that are addressed to him. When unloaded, the driver execute a cleanup function that cleans everything that was used by the driver, unlike an user mode application a driver has to be very 3

rigorous about it because remaining pieces will stay until reboot. The cleanup function should also tell the kernel that the module is no longer loaded and should not be invoked. Linux device management An important thing to remember about Unix based operating system is what is known as Everything is a file. Indeed with the exception of network interfaces, all devices are accessed through file. It makes an easy way to access all kind of device through a common interface with a few specific extensions. Device files can be found in the /dev directory. 4

Examples of device drivers and some tips to make them Three categories of devices are defined; the character devices, the block devices and the network interfaces. The main difference between these different types is the way they are addressed. The character devices are like files accessible as a stream of bytes. The driver is responsible for at least opening and closing these files. It can also allow write and read in it. These devices can also be addressed through file system nodes. Their address usually looks like that: /dev/ttys0 for the serial port, /dev/lp0 for a printer... There is one notable difference with classic files. Some char devices (not all of them) can be accessed only sequentially meaning that one can not move back and forth. The block devices are also accessible through their nodes but they can transfer a much greater amount of bytes than a char device. The drivers of these two categories are different but they appear to the user to have the same way of working. The network interfaces cannot be addressed in file system because they deal only with network packets. But this classification is not exclusive in the sense that a driver can belong to the three categories. For example a USB module can be considered as a char device if it is a USB serial port, as a block device if it is a memory card reader or as a network interface if it is a USB Ethernet interface. We are going now to deal with the features of writing drivers for these different categories of devices. char device drivers The char devices have the simplest drivers to write. They have several attributes as illustrated below by a view of the command ps -l in a /dev directory: crw-rw-rw- 1 root root 1, 3 Mar 16 2012 null The first character reminds the type of the device (c for character). The two numbers after root are called the major and the minor device number. The major number refers to the specific type of device among char device. There is for example the major 4 that refers to serial interfaces. 5

The minor number is specific to any single device and can be used to address a device. These number can be implemented with several functions available in <linux/fs.h>. It is possible to give numbers to the device among a list of available numbers with a call to the function: int register_chrdev_region(dev_t first, unsigned int count, char *name); It is also possible to let the system give dynamically numbers to the device with a call to the function: int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name); Then it can be relevant to free the device numbers in order to let the system allocate it again with a call, when the module is cleaned, to the function: void unregister_chrdev_region(dev_t first, unsigned int count); Of course a driver must implement a lot of other characteristics of the device. We are going to give a short presentation of the most important methods that have to be implemented by a driver : owner is a pointer to the module in which the structure is. It is often initialized with a macro named THIS_MODULE. llseek allows to move from the current read/write position in the file. read allows to read a data from the file. write allows to send a data to the device. ioctl allows to deal with commands that are specific to the device. open allows to open the device. It the first operation complete when using a device. release allows the release of the structure. There are many devices whose driver works this way such as serial ports, parallel ports, keyboards, sound cards... Block device drivers We call a block device a device whose data is available through random access of constant sized blocks. This is the way to access data stored on a hard drive for example, you specify the location you want to access and then read or write data by blocks. Such devices can be critical for the system and performance is a key factor. This is why the kernel interface for them is more complex and more powerful than char devices. When looking at /dev, block devices appears like : 6

brw-rw---t 1 root disk 8, 0 mars 9 03:02 sda The b at the beginning of the line stands for block device and the two numbers after disk are the major and minor numbers. The remaining information is the same that for standard files. In a similar way than for char drivers, the block driver should register a major number identifying the driver and one or several minor numbers identifying the disk and its possible partitions. Block drivers make their operations available through the bloc_device_operations structure, which is quite similar to the file_operation structure used by char drivers. It can also register open, release, or ioctl functions but there is no functions actually meant to read or write data. Instead of that there is a request function whose working makes the specificity of block drivers. During its initialisation, block driver is initializing a message queue whose purpose will be to hold the different I/O request made to the device. The kernel put in this queue all the requests to do and when it thinks it is a good time, calls the register function of the driver. The register function doesn t have to empty the queue or even to fully accomplish any of the request but it should start them and ensure that they will all finally be accomplished. This system of queues allow the block drivers to have a finest management of requests than executing them linearly. For instance in the case of the hard drive, reordering the requests may allow to access more contiguous segments and avoid unnecessary movements of the read/write head. Nevertheless in the case of real random access device (a RAM for instance), the queue might be useless, so it is possible to bypass the queue mechanism by providing a make request function. Block devices are usually accessed through filesystems that make full use of their features. Network interface drivers The last class of drivers defined by the Linux kernel is the network drivers class. It differs from char and block drivers because it is not only supposed to operate in response to kernel requests but also to be able to receive data from outside. Network drivers are independent from the protocol that will be used to transmit data. Like we mentioned before, network interfaces are the only exceptions to the everything is a file rule. Instead of being accessible through a file with a major and minor number, each new network interface is inserted in a global list of network devices. Just like char and block drivers, network drivers register the set of methods that they will be able to perform. We recognize the open method that is called when ifconfig activates the interface. The stop method is called when deactivating the interface. And amongst some others the hard_start_xmit that initiate the transmission of a packet. In order to send data on the network, the kernel calls the hard_start_xmit function with a socket buffer structure in argument. This socket buffer contains the packet as it should be 7

transmitted and some headers for transmission. On the other hand, packet reception is a bit trickier. It can be done both based on polling or interruptions. The driver has to get the data from the outside, store them in a socket buffer and transmit it to the upper layers of the kernel. Conclusion Linux driver devices can be reduced to very simple executable pieces of code. However they have a crucial importance as they allow to make a link between the software layer and the hardware layer. It also brings a level of abstraction: one can create hardware without taking care about how the operating system will work and on the other hand one can create software without taking care about how the hardware work. But the consequences of mistake can be much heavier. Where a bug into a software code will cause, in the worst case to the crash of the session, a bug in a driver device can lead to the degradation of the material that can even be harmful for the user. Bibliography Linux Device Drivers, Third Edition (by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman) 8