Linux Simple character device driver (top-down)

The 0th chapter: The Tug of the light

To summarize the process of writing a simple character device driver, I would like to highlight the "top down" approach, because I think it is easier to understand that the child shoes that do not have contact with the device driver are more understandable, "top-down" was originally learned from the book "Computer network Top-down method", I think it's a good way sometimes.

Chapter One: Test procedures

Hey? How can you be different from other people's ideas??? From top to bottom, I'm going straight from the test program, so isn't that more familiar? Look at the code of the test program below, is it familiar?

1#include <stdio.h>2#include <unistd.h>3#include <fcntl.h>4 5 #defineMy_cdev_name "/dev/mychardev"6 #defineBuf_len 167 8 intMainvoid)9 {Ten     intFD; One     intret,i; A     CharBuf[buf_len]; -      -     /*turn on the device*/ theFd=open (My_cdev_name,o_rdwr |o_nonblock); -     if(fd<0) -     { -printf"Open%s fail!\n", my_cdev_name); +         return-1; -     } +printf"Open%s success!\n", my_cdev_name); A      at     /*set the BUF data, which will be written into the device later*/ -      for(i=0; i<buf_len;i++) -     { -buf[i]=i+ $; -     } -      in          -     /*Write Device*/ to     if((Ret=write (Fd,buf,buf_len)) <0) +     { -printf"Write%s fail!\n", my_cdev_name); the     } *     Else $     {Panax Notoginsengprintf"Write%s success! Write totoal:%d\n", My_cdev_name,ret); -     } the      +     /*set the file offset to the beginning of the file*/ A     if(Ret=lseek (FD,0, Seek_set)) <0) the     { +printf"Lseek%s fail!\n", my_cdev_name); -     } $     Else $     { -printf"Lseek%s success! Now position:%d\n", My_cdev_name,ret); -     } the      -     /*Reading Equipment*/Wuyi     if((Ret=read (fd,buf+buf_len/2, Buf_len)) <0) the     { -printf"Read%s fail!\n", my_cdev_name); Wu     } -     Else About     { $printf"Read%s success! Read totoal:%d\n", My_cdev_name,ret); -     } -      -      for(i=0; i<buf_len;i++) A     { +printf"buf[%d]:%c\n", I,buf[i]); the     } -      $ Close (FD); the      the     return 0;  the}

Final Test Code

This is not really the UNIX environment to open a normal file, I opened the/dev/mychardev, although it is a character device files, but the operating system unified interface, so and open a normal file no difference, first open (), then to the file write (), Set the current file offset to Lseek () at the beginning of the file, read read again (), and close the close (). Write these code more think Linux is really powerful, basically put all the equipment as files to dispose of, the system provides a unified interface to the upper, cool!

There is basically no problem here, the only question is/dev/mychardev how did this file come from???

Chapter II: How did the device files come from?

0, the Linux file type simple introduction:

The Linux system basically divides the device into 3 categories: Character devices, block devices, network devices. Please search for details, I will not tell you that I do not understand deeply enough ...

1. First look at this file attribute:

Look at the front is "C", description is a character device file. I will not tell you that this file was created by myself, O (∩_∩) o haha ~

2, Linux to create a character device file is simple, as long as the Mknod command:

Make it very clear that you create a character or block special device file. So it's easy to create a character device:

sudo mknod/dev/mychardev C 248 0

Look, this does not create a character device file, sudo to get permission;/dev/mychardev is the file name, in fact, it also specifies the path of the files, C indicates that a character device file is created, the block device file is B, and the last important is the major and minor two parameters, I was created with 248 and 0 replaced, this is not a mess, there is a story!

3. Why in the/dev directory:

Linux/dev directory, is stored in the system of various device files, each device corresponding to a device file, and we are through this device file access and use of this device, that is, open this file equivalent to open the device, write data to the file is equivalent to the data written to the device, Reading the file is equivalent to reading the data from the device. We do not want to create a character device, although we do not know what this device is specific, but there is always a device file to correspond to this device.

4, equipment file primary and secondary equipment number:

As you can see from the previous section, the/dev directory is a variety of assorted device files, how do these device files correspond to the device? They have two good friends who must correspond to each other. To manage these devices, the operating system has numbered the devices, and each device number is divided into the main device number and the secondary device number.

From device files and devices: The main device number is used to differentiate between different kinds of devices, and the secondary device number is used to differentiate multiple devices of the same type.

From device files and device drivers: The main device number is used to identify the driver that is connected to the device file, which is used to reflect the device type, and the secondary device number is used by the driver to identify which device is being used to distinguish between devices of the same type.

The above two angles mean the same. For example: If my computer is connected to 2 printers, the printer type is exactly the same, then according to the above, in the/dev directory there will definitely be 2 device files to correspond to the 2 printers, such as the/dev/printer1 and/dev/printer2, The reading and writing of these two files is actually a read and write operation for printers 1 and 2. But because the two printer types are the same, aren't their drivers the same? No need to load 2 of the same driver code into the operating system kernel? So let the two files of the main device number is the same, for example, all 248. Well, we loaded a driver module into the kernel, how does the driver know which printer to send data to? This is the time the device number is working, such as assigning them 1 and 2 times the device number, so soon distinguished. So I can do this: sudo mknod/dev/printer1 C 248 0 and sudo mknod/dev/printer2 C 248 1. This creates 2 device files to correspond to the 2 devices.

OK, here's how the device file came to be solved: I created the chant. So the only problem is the main device number and the secondary device number how come???

Chapter III: Loading the device driver module into the system

There is no introduction to the previous chapter of the main device number and the second device number of the problem, because it is in the process of execution from the system, depending on the code, but in the driver loading to the system will execute a function, generally in this function for the system to the device number, so you can print in this function to obtain the device number. So when the driver module is loaded into the system you can see the device number, if you must write a printing function.

This chapter is about how you should load a specific device driver into the system if you have already written it. Look at the following folder:

I wrote the driver of the source file only one: Mycdev.c, this, there is makefile, plus test.c and a is the test source files and generated test program. The rest is generated when the make command is executed, that is, the generated file is compiled. There is a. ko file, which is closely related to the system load driver.

Since we are top-down, assuming that the lower layer already provides the source file, it has already been compiled and now loads the driver to the system as long as one command:

sudo insmod Mycdev.ko

Insmod is doing this thing. Corresponds to:

sudo rmmod Mycdev

is to unload the module, the module can be removed directly from the kernel, note that insmod has a. Ko suffix, this is not.

Here are two commands; DMESG and cat/proc/kmsg can view the output of your PRINTK () function in the source code, because a specific function is typically called when the module is loaded and unloaded.

Well, this chapter solves the problem of how to load if we have written the driver and compiled it well.