"Atomic Linux Driver Development" Basic Reading 1: Understanding Character Device Driver Development
[Copy link]
Character device driver development is the most basic part of Linux driver development, and the focus is on learning the character device driver development framework.
Character device drivers are the most basic type of devices in Linux drivers. Drivers for character devices are devices that read and write byte by byte according to byte streams. For example, common IO operations, buttons, SPI, etc. are all character devices. The drivers for these devices are called character device drivers.
So, how do you call the driver in an application? The application calls the corresponding library through the API function, then enters the kernel, and the corresponding function in the driver performs specific hardware device actions:
The application runs in user space, and the driver is part of the kernel. Therefore, the driver's running memory is actually the application's operation on the kernel, but the user space cannot directly operate the kernel. At this time, the user's operation on the kernel space is implemented through the system call method. The application uses specific functions in the C library and then operates the kernel through system calls to implement specific driver operations. Therefore, driver development is actually a low-level development.
Linux kernel driver development specifically implements the most common read, write, open, close and other functions in the driver. These functions have specific function structures in Linux and must conform to the specific architecture.
So, what steps should be followed in character device driver development? When we develop bare metal devices, we must initialize peripherals. Linux driver development is no exception, and it needs to be written according to its prescribed framework. In Linux driver development, the focus is on learning its driver framework.
There are two operating modes for Linux drivers. One is to compile the driver into the Linux kernel, and the other is to compile the driver into a module and load the driver module using a command. Relatively speaking, the method of compiling into a module has many advantages. For example, when debugging, we only need to compile the driver code, and do not need to compile all of it. The overall compilation is still very time-consuming and the download is also slow. During the debugging stage, it is recommended to compile it into a module for debugging, and it can be written into the kernel after the test is correct. There are two modes of operation for module operation: loading and unloading. For character device drivers, the character device needs to be registered after successful loading, and the corresponding character device needs to be unregistered after successful unloading.
At this time, we need to distinguish each device. Each Linux device has a device number, which consists of a major device number and a minor device number. The major device number represents a specific driver, and the minor device number represents each device using this driver. Linux provides a data type called dev_t to represent the device number. The dev_t type is an unsigned 32-bit data type, which means that the range of its device number is 0 to 4095. Do not exceed this range when setting it. There are two allocation methods: static allocation and dynamic allocation. One is to directly give it a fixed number, and the other is to select an unused number for allocation based on the device number used in the retrieval system. The dynamic allocation method can avoid conflicts.
|