Working with Char Drivers

A device driver is special code (running in kernel space) that interfaces a physical device to the system and exports it to the user space processes using a well-defined API, that is, by implementing some system calls on a special file. This is due to the fact that, in a Unix-like OS, everything is a file and physical devices are represented as special files (usually placed in the /dev directory), each one connected to a particular device (so, for instance, the keyboard can be a file named /dev/input0, a serial port can be a file named /dev/ttyS1, and a real-time clock can be /dev/rtc2).

We can expect that network devices belong to a particular set of devices not respecting this rule because we have no /dev/eth0 file for the eth0 interface. This is true, since network devices are the only devices class that doesn't respect this rule because network...

Technical requirements

Throughout this chapter, we'll need whatever we used in Chapter 1, Installing the Development System, and Chapter 2, A Peek Inside the Kernel, so please refer to them for cross-compilation, kernel modules loading and management, and so on.

For more information on this chapter please read the Appendix.

The code and other files used in this chapter can be downloaded from GitHub at https://github.com/giometti/linux_device_driver_development_cookbook/tree/master/chapter_03.

Creating the simplest char driver

In the Linux kernel, three major device types exist—char device, block device, and net device. And of course, we have three major device driver types; that is, char, block, and net drivers. In this chapter, we're taking a look at a char (or character) device, which is a kind of peripheral that can be accessed as a stream of bytes, such as a serial port, audio device, and so on. However, in this recipe, we're going to present a really basic char driver, which simply registers itself and does nothing more than this. Even if it may seem useless, we will discover that this step really introduces plenty of new concepts!

Actually, it could be possible to exchange data between peripherals and user space without a char, block, or net driver but by simply using some mechanism offered by the sysfs, but this is a special case and it is...

Exchanging data with a char driver

In this recipe we'll see how to read and write data to and from a driver according to read() and write() system calls behaviors.

Getting ready

To modify our first char driver in order to allow it to exchange data between user space we can still work on the module used in the previous recipe.

How to do it...

In order to exchange data with our new driver, we need to modify the read() and write() methods according to what we said earlier, and we have to add a data buffer where exchanged data can be stored:

1. So, let's modify our...

Using the "Everything Is a File" abstraction

When we introduced device drivers we said that they lay under the Unix file abstraction; that is, in a Unix-like OS, everything is a file. Now, it's time to verify it, so let's see what happens if we try to execute some file-related utility programs against our new driver.

Thanks to our latest modifications to the chrdev_legacy.c file, our driver simulates a file 300 bytes long (see the chrdev_buf[BUF_LEN] buffer where BUF_LEN is set to 300), where we're able to execute read() and write() system calls on it, just as we do on a normal file.

However, we may still have some doubts, so let's consider standard cat or dd commands, as we know they are utilities useful to manipulate files content. For example, in the man pages of the cat command, we can read the following definition:

NAME
       cat - concatenate...