directory
- Three basic types of drivers
- Device driver functionality
- Kernel module mechanism for drivers (development mode)
- Driver framework
-
- Three main parts
- 1. Character device driver framework
- 2. Block device driver framework
- 2. Network device driver framework
Three basic types of drivers
1. Char Device 2. Block Device 3. Net Device
Device driver functionality
Initialize and release the device. Transfer data from the kernel to the hardware and read data from the hardware. Read data sent to the device file by the application program and send back data requested by the application program
Access to specific hardware: Access to specific hardware is access to physical addresses (such as registers of devices within the processor, address maps of peripherals). However, due to MMU’s memory mapping and protection of the operating system, applications running in user mode generally cannot directly access hardware addresses. The driver is therefore needed as the intermediary between the application and the access hardware.
Kernel module mechanism for drivers (development mode)
Statically compiled, dynamically loaded Linux provides a kernel module mechanism. Once a module is compiled as a separate kernel module, it may not be compiled into the entire kernel at first. When the kernel needs to be added to the module, it does not need to recompile the entire kernel, but just insert (load) the kernel module into the running kernel. Similarly, you can uninstall it from a running kernel.
Linux device drivers can be compiled and loaded in two ways: 1. The driver is directly compiled into the Linux kernel and loaded with Linux startup. 2, compile into a loadable and delete module, load with insmod, rmmod delete.
Driver framework
Three main parts
1. Device initialization/release:
Responsible for initializing and releasing the device
Initialization checks whether the hardware device to be driven exists and works properly. If the device is normal, the device and related drivers
The required software state is configured/initialized.
2. Upper part: serves file system I/O
Responsible for: reading data from the application through the file system and sending data back to the application through the file system (file system layer <-> device driver layer)
This part is performed by the filesystem specific system call, which belongs to the same process as the calling process and has the running environment of the calling process, but has changed from user mode to kernel mode.
3. The lower part: I/O for hardware devices
Responsible for: transferring data from kernel to hardware, reading data from hardware to kernel (device driver used <-> hardware layer)
This part can be implemented in interrupt mode, which can improve CPU processing efficiency on most devices.
This part can also be achieved without interruption, as long as the data communication between the device driver layer and the hardware can be completed.
