I. Relationship between device management and file management
1. file operations are the organization and abstraction of device operations
Device operations are the final implementation of File Operations
Ii. Device Driver Model
1./sys -----> bus -----> PCI -----> driver -----> serial port -----> Device
2. Several main layers of the device driver model:
(1) bus, see linux2.6
I/O Architecture
(2) PCI bus, see section 3
(3) See driver 4.
(4) device. See figure 5.
Iii. PCI Bus
1. Address Allocation Policy
The I/O address space is separated from the memory space. The address of the I/o register is mapped to the memory address and these registers are operated through the memory instruction.
2. Bus competition strategy
(1) equipped with a time-sharing arbitration server. In case of conflict, the arbitration server selects a device to temporarily become the "main device", and the rest wait
(2) provide a "write buffer". When a write operation cannot use PCI due to a bus conflict, put the content to be written into the buffer and entrust it to PCI.
(3) from a device to a master device through competition, it is an extension of DMA
3. Bus Expansion Policy
The CPU is connected to the primary PCI through the host-Bus Bridge, and the bus can be extended to a tree through the PCI-PCI bridge or PCI-ISA Bridge, external devices are directly or indirectly connected to the CPU through the primary PCI or other layer PCI
Bridge is also an external device
4. Access a register of a device
Set the configuration register group of all devices to the same address, which is distinguished by other conditions attached to the PCI Bridge of the bus.
The CPU sends a command to the host-PCI bridge through a unified entry address, and the corresponding PCI bridge indirectly completes the specific read/write operations.
When accessing a register of a device, the CPU first writes the target address (including the bus number, device number, function number, and configuration register address) to the address register, the first three are the additional conditions mentioned above), and then read and write data through the data register.
4. Drivers
1. Driver
The driver implements the function interfaces (open, read, lseek, etc.) provided by VFS, so that the device responds to control from VFS.
To make the device visible in the system, you must (1) have a file node representing the device in the file system (2) have a driver for the device at the driver layer
In Linux, the "installable module" is used to dynamically install the driver.
2. Module
Module is the compiled but not connected target code (. o file), mainly implemented through system calls.
(1) Convenience: All symbols that can be "removed from export" in the kernel or other installed modules can be referenced in the module.
(2) Security: apart from these symbols and system calls, the module cannot access other resources in the kernel.
3. Install the driver module
(1) read module into user space
(2) Ask the kernel for the address "Remove the export symbol": query_module ()
(3) Establish a one-way link so that all symbolic references in the module are implemented.
(4) create a module structure. system space required for "Reservation": create_module ()
(5) load the module image that has completed one-way connection in the user space into the kernel: init_module ()
(6) register with the kernel. Some data structures init_module () in this module that contain function pointers are connected in two directions.
Note: (5) init_module () is different from init_module () in (6. (5) The system calls sys_init_module () and is unique in the kernel. (6) It is a function in each installable module.
4. sys_init_module ()
(1) select the target module and check
(2) Assign the module of the user space to the module of the kernel space
(3) re-verify that the dependent items are in the kernel
(4) chain each module_ref to the dependent items
(5) Start the init_module () of the execution module ()
The module does not have its own init_module (). However, the existence of the module is meaningless.
5. For the block device drivers, see linux2.6 block device drivers.
5. Devices
1. The device file is the file that represents the device in the file system. Linux treats an I/O device file as a special file. The same system call used for interaction with common files can be directly used for I/O devices.
The device file occupies only one index node on the device where the file system is located, and there is no record block for storing data.
The existence of device files is not to access data, but to provide an access path to a specific device for the application, so that the application can establish a connection with a specific device.
2. device files can be divided into two types: Block devices and character devices.
3. Create a device file sys_mknod
(1) obtain the path name of the target
(2) obtain the parent dentry and vfsmount of the target.
(3) locate or create the dentry of the target
(4) If a common file is to be created, vfs_create (): See the system call to open a file in linux2.4.
If a special file is to be created, vfs_mknod (): see Figure 4.
If the target file is to be created, an error occurs.
4. Create a device node vfs_mknod (), Dir-> I _op-> mk_nod (), ext2_mknod ()
(1) various checks
(2) create an inode
(3) initialize inode
(4) Add the newly created inode to the directory file on the disk.
(5) inode dirty queue mounting
(6) Hook the dentry and inode in the memory
Vi. Monitor I/O operations
The duration of the I/O operation is unpredictable, so it is necessary to monitor when the I/O operation ends.
1. Polling mode: the CPU repeatedly checks the Status Register of the device until the value of the Register indicates that the I/O operation has been completed.
2. interrupt mode: the I/O controller sends an I/O operation end signal through the IRQ line.
3. DMA: an auxiliary DMA circuit is used to control data transmission between RAM and I/O devices. Once the DMA is activated, the data can be transmitted by itself. After the data is transferred, the DMA sends an interrupt request.