Chapter 4: Writing Character Device Drivers

Unix-based systems expose hardware to user space by means of special files, all created in the /dev directory upon device registration with the system. Programs willing to access a given device must locate its corresponding device file in /dev and perform the appropriate system call on it, which will be redirected to the driver of the underlying device associated with that special file. Though system calls redirection is done by an operating system, what system calls are supported depends on the type of device and the driver implementation.

On the topic of types of devices, there are many of them from a hardware point of view, which are, however, grouped into two families of special device files in /dev – these are block devices and character devices. They are differentiated by the way they are accessed, their speed, and the way data is transferred between them and the system. Typically, character devices are slow and transfer data...

The concept of major and minor

Linux has always enforced device file identification by a unique identifier, composed of two parts, a major and a minor. While other file types (links, directories, and sockets) may exist in /dev, character or block device files are recognizable by their types, which can be seen using the ls -l command:

$ ls -la /dev
crw-------  1 root root    254,     0 août  22 20:28 gpiochip0
crw-------  1 root root    240,     0 août  22 20:28 hidraw0
[...]
brw-rw----  1 root disk    259,     0 août  22 20:28 nvme0n1
brw-rw----  1 root disk    259,     1 août  22 20:28 nvme0n1p1
brw-rw----  1 root disk    259,     2 août ...

Character device data structure introduction

A character device driver represents the most basic device driver in the kernel sources. Character devices are represented in the kernel as instances of struct cdev, declared in include/linux/cdev.h:

struct cdev {
    struct kobject kobj;
    struct module *owner;
    const struct file_operations *ops;
    dev_t dev;
[...]
};

The preceding excerpt has listed elements of our interest only. The following shows the meaning of these elements in this data structure:

• kobj: This is the underlying kernel object for this character device object, used to enforce the Linux device model. We will discuss this in Chapter 14, Introduction to the Linux Device Model.
• owner: This should be set with the THIS_MODULE macro.
• ops: This is the set of file operations associated with this character device.
• dev: This is the character device identifier.

...

Creating a device node

The creation of a device node makes it visible to users and allows users to interact with the underlying device. Linux requires intermediate steps before the device node is created and the following section discusses these steps.

Device identification

To precisely identify devices, their identifiers must be unique. Although identifiers can be dynamically allocated, most drivers still use static identifiers for compatibility reasons. Whatever the allocation method, the Linux kernel stores file device numbers in elements of dev_t type, which is a 32-bit unsigned integer in which the major is represented by the first 12 bits, and the minor is coded on the 20 remaining bits.

All of this is stated in include/linux/kdev_t.h, which contains several macros, including those that, given a dev_t type variable, can return either a minor or a major number:

#define MINORBITS    20
#define MINORMASK    ((1U << MINORBITS...

Implementing file operations

After introducing file operations in the previous section, it is time to implement those to enhance the driver capabilities and expose the device's methods to user space (by means of system calls, of course). Each of these methods has its particularities, which we will highlight in this section.

Exchanging data between the kernel space and user space

As we have seen while introducing the file operation table, the read and write methods are used to exchange data with the underlying device. Both being system calls means that data will originate from or be in destination to user space. While looking at the read and write method prototypes, the first point that catches our attention is the use of __user. This is a cookie used by Sparse (a semantic checker used by the kernel to find possible coding faults) to let the developer know they are about to use an untrusted pointer (or a pointer that may be invalid in the current virtual address mapping)...

Summary

In this chapter, we have demystified character devices, and we have seen how to let users interact with our driver through device files. We learned how to expose file operations to user space and control their behavior from within the kernel. We went so far that you are even able to implement multi-device support.

The next chapter is a bit more hardware-oriented, as it deals with the device tree, a mechanism that allows hardware devices present on the system to be declared to the kernel. See you in the next chapter.