Device drivers in LINUX

Article title: device drivers in LINUX. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
3. device drivers in UNIX systems
　　
3.1 Basic structure of device drivers in UNIX
　　
In UNIX systems, the device driver hides the details of the device and provides consistent interfaces for different devices, generally, a device is mapped to a special device file. a user program can operate the device file like other files. UNIX supports two standard interfaces for hardware devices: block special device files and character special device files. devices that are accessed by block (character) special device files are called blocks (characters) device or interface with a block (character) device.
　　
The block device interface only supports block-oriented I/O operations. all I/O operations are performed through the I/O buffer in the kernel address space, it supports I/O requests of almost any length and any location, that is, it provides random access.
　　
The character device interface supports character-oriented I/O operations, which are not cached by the system, so they are responsible for managing their own buffer structures. The character device interface only supports sequential access. Generally, I/O requests of any length are not allowed, but the length of I/O requests must be a multiple of the basic block length required by the device. Obviously, the serial card driven by this program can only provide the sequential access function, which is a character device. Therefore, we will discuss the differences between the two devices and only the interface of the serial device.
　　
A device is identified by a primary device number and a secondary device number. The primary device ID uniquely identifies the device type, that is, the device driver type. it is an index of the device table items in the block device table or character device table. The device number is interpreted only by the device driver. it is generally used to identify the device involved in an I/O request among several possible hardware devices.
　　
Device drivers can be divided into three main components:
　　
(1) automatic configuration and initialization subroutines are used to detect whether the hardware device to be driven exists and whether the hardware device can work properly. If the device is normal, initialize the device and the software status required by the device driver. These drivers are called only once during initialization.
　　
(2) subprograms serving I/O requests, also known as the upper half of the driver. This part is called by the system. During the execution of these programs, the system still considers that the called process belongs to the same process, but the user state has changed to the core state, the runtime environment of the user program that calls this system. Therefore, you can call functions related to the process runtime environment, such as sleep.
　　
(3) interrupt service subprogram, also known as the lower half of the driver program. In UNIX systems, the interruption service subroutine of the device driver is not directly called from the interrupt vector table, but is received by the UNIX system and then called by the system. Interruption can occur when any process is running. Therefore, when the interrupted service program is called, it cannot depend on the status of any process, therefore, you cannot call any function related to the process runtime environment. Because device drivers generally support several devices of the same type, when the system calls the interrupt service subroutine, one or more parameters are carried to uniquely identify the device requesting the service.
　　
In the system, access to I/O devices is performed through a set of fixed entry points, which are provided by the device drivers of each device. Generally, the drivers of devices provide the following entry points:
　　
(1) open entry point. Open the device to prepare for the I/O operation. When you open a special device file, the open entry point of the device is called. The open subroutine must make necessary preparations for the I/O operations to be performed, such as clearing the buffer zone. If the device is exclusive, that is, only one program can access the device at the same time, the open subroutine must set some signs to indicate that the device is busy.
　　
(2) close the entry point. Disable a device. After the last device termination, call the close subroutine. An exclusive device must be marked as a device that can be used again.
　　
(3) read entry point. Read data from the device. For I/O operations with a buffer, data is generally read from the buffer. The read subroutine is called to read special device files.
　　
(4) write entry point. Write data to the device. For I/O operations with a buffer, data is generally written into the buffer. The write subprogram is called to write special device files.
　　
(5) ioctl entry point. Perform operations other than read and write operations.
　　
(6) select entry point. Check the device to see whether the data is readable or whether the device can be used to write data. The select system call uses the select entry point when checking the file descriptors related to the device's special files. If the device driver does not provide one of the above entry points, the system will use the default subroutine instead. There are also some other entry points for different systems.
　　
3.2 device drivers in LINUX
　　
In LINUX, the entry points provided by the device driver are described to the system by a structure, which is defined:
　　
# Include
Struct file_operations {
Int (* lseek) (struct inode * inode, struct file * filp,
Off_t off, int pos );
Int (* read) (struct inode * inode, struct file * filp,
Char * buf, int count );
Int (* write) (struct inode * inode, struct file * filp,
Char * buf, int count );
Int (* readdir) (struct inode * inode, struct file * filp,
Struct dirent * dirent, int count );
Int (* select) (struct inode * inode, struct file * filp,
Int sel_type, select_table * wait );
Int (* ioctl) (struct inode * inode, struct file * filp,
Unsigned int cmd, unsigned int arg );
Int (* mmap) (void );
Int (* open) (struct inode * inode, struct file * filp );
Void (* release) (struct inode * inode, struct file * filp );
Int (* fsync) (struct inode * inode, struct file * filp );
};
　　
Here, struct inode provides information about the special device file/dev/driver (assuming this device is named driver), which is defined:
　　
# Include
Struct inode {
Dev_t I _dev;
Unsigned long I _ino;/* Inode number */
Umode_t I _mode;/* Mode of the file */
Nlink_t I _nlink;
Uid_t I _uid;
Gid_t I _gid;
Dev_t I _rdev;/* Device major and minor numbers */
Off_t I _size;
Time_t I _atime;
Time_t I _mtime;
Time_t I _ctime;
Unsigned long I _blksize;
Unsigned long I _blocks;
Struct inode_operations * I _op;
Struct super_block * I _sb;
Struct wait_queue * I _wait;
Struct file_lock * I _flock;
Struct vm_area_struct * I _mmap;
Struct inode * I _next, * I _prev;
Struct inode * I _hash_next, * I _hash_prev;
Struct inode * I _bound_to, * I _bound_by;
Unsigned short I _count;
Unsigned short I _flags;/* Mount flags (see fs. h )*/
Unsigned char I _lock;
Unsigned char I _dirt;
Unsigned char I _pipe;
Unsigned char I _mount;
Unsigned char I _seek;
Unsigned char I _update;
Union {
Struct pipe_inode_info pipe_ I;
Struct minix_inode_info minix_ I;
Struct ext_inode_info ext_ I;
Struct msdos_inode_info msdos_ I;
Struct iso_inode_info isofs_ I;
Struct nfs_inode_info nfs_ I;
} U;
};
　　
Struct file is mainly used for device drivers corresponding to the file system. Of course, other device drivers can also use it. It provides information about the opened file, defined:
　　
# Include
Struct file {
Mode_t f_mode;
Dev_t f_rdev;/* needed for/dev/tty */
Off_t f_pos;/* Curr. posn in file */
Unsigned short f_flags;/* The flags arg passed to open */
Unsigned short f_count;/* Number of opens on this file */
Unsigned short f_reada;
Struct inode * f_inode;/* pointer to the inode struct */
Struct file_operations * f_op;/* pointer to the fops struct */
};
　　
In the file_operations structure, the entry points provided by the device driver are shown as follows:
　　
(1) lseek: the position of the pointer to move a file. Obviously, it can only be used for devices with random access.
　　
(2) read: perform read operations. The buf parameter is the buffer that stores the read results, and the count parameter is the length of the data to be read. If the returned value is negative, the read operation is incorrect. Otherwise, the actual number of bytes read is returned. For the bytes type, both the number of bytes read and the actual number of bytes returned must be a multiple of inode-> I _blksize.
　　
(3) write, which is similar to read.
　　
(4) readdir: Get the Next Directory entry point, which is used only by the device driver related to the file system.
　　
(5) select the device. if the driver does not provide a select entry, the select operation considers the device to be ready for any I/O operations.
　　
(6) read and write operations other than ioctl. the cmd parameter is a custom command.
　　
(7) mmap,