Actually, it's not hard to develop Linux system device drivers.

Recently read a lot of kernel programming and drive development tutorials, also refer to some of the Development Board examples. The conclusion is not as high as you can imagine. Developing a driver requires a certain understanding of the kernel, not a thorough interpretation.

The drivers referred to below are for specific devices and are made to work in dynamic loading of modules. The driver framework is layered, some drivers are not for specific devices such as ext2 file system drive, TCP/IP protocol driver, etc., which can be called soft drive, work on other specific device drivers. As we do is embedded development, just write the lowest level of device drivers can be.

Device drivers are typically classified as character devices and block devices. The difference is that there is a buffer is a block device, no buffer is the character device. But in the Linux source drivers directory, not only block and char directory, there are other devices, it is because some developers for convenience and not based on this classification but the use of more intuitive functional classification. For example, the sound directory, you can see that there are a variety of audio drivers stored.

Since it's a device driver, let's look at how the device is described in Linux. All devices with system support are stored in the/dev directory. The device can also be a device node, and if a new device is added to the system, the corresponding node must be created under/dev. A device driver can often drive several devices, which are distinguished by the main device number and the secondary device number. All devices with the same main device number use a driver. The secondary device number provides the driver with a way to differentiate between different device entrances. In some cases, the device's working type can be differentiated according to the height of the secondary device number 4 bits. For example, the relationship between Hda0-hda4 and HDB0-HDB4, HDA represents the first hard drive, HDB represents the second hard drive, because everyone is a hard drive so this uses the same driver, so had and HDB the main device number is the same. HDA after the serial number represents the partition information on the hard disk, in order to effectively differentiate these partitions, the secondary device was set up to do a classification, the byte of high four-bit representing different hard disk, and low 4-bit represents the partition index.

Understanding the description of the device, we look at the software environment. Developing Linux drivers is irrelevant to the distribution you use, regardless of whether you use Redhat or mandrake. What really affects you is the version of the kernel you are currently using. If you're going to use a 2.4.x kernel on the target board, and Linux on your mainframe is 2.6.x, your development will be a hassle. The problem is where you look down and you get it. Therefore, we recommend that the host and target systems adopt the same kernel version.

During the development drive, because of the kernel reference, it is not necessary to link to the library file when the program is compiled. So the Lib path is useless to us. However, because you need to refer to the various data structures and interfaces provided by the kernel, you must set the appropriate version of the include path, usually in/usr/include. There are a lot of headers under/usr/include, and all we need is a/usr/include/linux directory and a/usr/include/asm directory.

There are two functions and three data structures that are most important in driver programming. Init_module and Cleanup_module these two functions. File_operations,inode,file These three data structures, defined in linux/fs.h. As for other memory operations, I/O operations, timers, interrupts, DMA waiting are all part of the Ascension.