LDD Reading Notes-character device drivers

Driver for writing character DevicesProgramGeneral process:

Define the capabilities (Mechanisms) provided by the driver for the user program );

Determines the core data structure of a module, for example, describing a device or the storage form of the device data in the memory;

Determine the master and secondary device numbers;

You can use/proc/devices to obtain the device's master device number, and then output the device file in mknod under/dev;

Compile the init and exit functions of the module;

Compile functions in the file_operations structure: Open release, read write, etc;

Understanding of file_operations, file and inode

The file_operations structure, which corresponds to the device numbers one by one. It provides external (or upper layer) with the method to operate the device. Besides the owner used to point to the module, the other functions are callback functions. The module completes the corresponding callback-that is, the method based on its own capabilities and requirements.

Created by a programmer and stored in the corresponding module. The life cycle is equivalent to the life cycle of the module. All members are filled by the programmer.

File structure. Any opened file has a corresponding file structure in the kernel. Therefore, it corresponds to the device file one by one and describes its related file attributes. Methods In file_operations basically carry this structure as a parameter. The file structure has two important members. f_op points to the file_operations structure corresponding to the device file and describes the methods available in the file, private_data describes the private data of a device in the memory. It should direct to the structure that describes the device.

Created by the kernel, the life cycle begins with "Open finally close", and at least the member "private_data" must be entered during "open.

Inode structure, which is also used to describe files and corresponds to device files. Different from file, file is a descriptor. "There may be many file structures that indicate open file descriptors, but they all point to a single inode structure ". I _cdev on the member points to the internal structure of the character device under the module, which should generally be stored in the structure that describes the device.

Created by the kernel. The lifecycle is the same as that of the file. All members are entered by the kernel.

Description module structure

The structure of the scull module is defined as follows:

 
Struct scull_dev {struct scull_qset * data; int quantum; int qset; unsigned long size; unsigned int access_key; struct semaphore SEM; struct cdev ;};
 

The visible structure members are mainly structures related to private data and necessary character devices. Specifically, data quantum qset size is used to point to private data and describe the storage form of private data in memory.

Character device Initialization

To put it simply, assign the device number-> define the method provided by the device (fill in the file_operations structure)-> perform the following operations on each device file: cdev_init-> enter the cdev structure and describe the device structure-> cdev_add.

Method overload

My understanding is to replace the method (callback function) to provide multiple different operations under the same device. In driver writing, as long as you can get the file structure, you can re-associate the f_op pointer in file to implement method overloading. Of course, most of them are method overloading during open.