Linux kernel (17)-Learn Linux drive development efficiently

This "Linux kernel cultivation of the road" has been on sale (online links for: excellence, when, china-pub), although serious literature, but in order to ensure fluency, most of the text I also are the words of the burning sentence, repeated read a few times to write up, as far as possible to consider the writing of each paragraph can make the reader have what doubts , and then it will be explained as soon as possible, many of the concepts in the middle have repeatedly tangled up how to explain the easier to understand, and even for beginners can have a very little hindrance to read. At the same time I also take part of the book's own sentiment out to organize the essence version, share out. Of course, the level is limited, errors and omissions found in the revision of the omission, there has not yet been found. If this book is useful to you, it is my blessing, if useless, I would like to first of all to worship a No.

The following is still part of the previous May presentation content and handouts, but then the title is called "Driving the development of the methodology", may be useful for everyone. The video of these lectures seems to be available online.

************************************************************************

We talked about how to learn the Linux kernel efficiently, and now we're going to start another topic of how to efficiently learn Linux driver development. As to why the choice of such a topic, mainly based on such two reasons:

The first reason: almost all of the current driver development aspects of the reference book, the content structure is to introduce what is the Linux driver, it is divided into what kind, and then the various types of device driver content details. Most are focused on the details of the various drivers themselves, but not in a holistic perspective on how to drive the development of the method. The result is that most driver developers, although they can write the driver correctly, are often only may not tress, but don't know why.

The second reason is: a lot of drivers, even if the developers have many years of experience, in the development of the driver is also filled with driver structure, for the more mature platform, is to find a similar driver on the Internet to modify, even write ten thousand thousands of drivers, that is, some hardware relatively familiar, Meet the new chip brand new platform on the helpless. It should be said that the understanding of the drive is very limited. This is also the current situation in the field of Linux drive development.

We first know about the fundamentals of Linux drivers, and the first thing we know about a new thing is to understand some of its basic information, just as we know each other first and foremost through personal basic information.

The Linux driver is essentially a software program, and the upper layer software communicates with the computer hardware without having to know the hardware characteristics of the interface that is provided by the driver.

A system call is an interface between the kernel and the application, and the driver is the interface between the kernel and the hardware, which is the bridge between the kernel and the hardware. It shields the application of hardware details so that, in the application's view, a hardware device is just a device file, and the application can operate on a hardware device as if it were a normal file.

Linux drivers are part of the kernel that manages the device controllers and corresponding devices in the system. It mainly accomplishes several functions: initializing and releasing the device, transmitting data to the hardware and reading from the hardware, and detecting and handling errors in the device.

In general, a driver can manage one type of device. For example, different USB drives belong to the mass storage device, and we do not need to write drivers for each USB drive, but only one driver to manage all these mass storage devices.

To facilitate the addition of various drivers to support different hardware, the kernel abstracts a number of hierarchies, which are the top layers of Linux device drivers. They abstract a variety of drive interfaces, and the driver only needs to fill in the corresponding callback function, it is easy to add new drivers to the kernel.

In general, Linux drives can be divided into three categories: block device drivers, character device drivers, and network device drivers. The block device reads and writes are cached to support, and the block device must be able to be randomly accessed. Block device drivers are primarily used for disk drives.

The I/O operation of the character device does not pass the cache. Character device operations are based on bytes, but do not say that only one byte operation can be performed at a time. For example, for character devices we can do a lot of data exchange through MMAP. The character device implementation is relatively simple and flexible.

Network devices are handled exclusively in Linux. Linux network system is mainly based on the BSD socket mechanism. Network device driver provides the interface for network operation, manages the transfer and send and receive of network data. To shield the diversity of physical network devices in a network environment, Linux abstracts and defines a unified concept for all physical devices called interfaces (interface). All access to the network hardware is through the interface, the interface to the upper layer protocol to provide a uniform set of operations to handle the basic data transmission and reception, the underlying shielding hardware differences. It differs from character devices and block devices in that the network interface does not exist in the Linux device file system/dev/.

As in the previous article, after the appearance, we look at the connotation, that is, the Linux-driven workflow. There are about four parts: use Insmod to load, initialize modules, perform device operations, and uninstall using Rmmod.

There are two types of Linux drivers exist, one is directly compiled into the kernel, when we configure the kernel, the corresponding option to select Y, the other is compiled into modules, loading and unloading on demand. Usually we use the INSMOD command to complete the loading of the module, and we can specify the module parameters at load time. Another common loading tool is modprobe, which differs from insmod in that it checks the dependencies between modules and loads the modules that the module relies on into the kernel.

Each driver has its own initialization function, which completes the registration of some new functions, which are used only at initialization time. In the Linux system, the device is in the form of files, the application can use open, read and other functions to manipulate the device, through the device files to achieve access to the device. When the device is no longer in use, we use the Rmmod command to unload it, the process of unloading calls to the driver's eject function, each driver must have an exit function, if not, the kernel will not allow to uninstall it.

After a preliminary understanding of the appearance and connotation of Linux drivers, let's look at what we need to be aware of as a driver developer.

First, the understanding of the module mechanism is the basis for the development of Linux drivers, because the process of writing a driver is the process of writing a kernel module. Earlier versions of the kernel were monolithic, meaning that all parts were statically connected to a large execution file. But now the kernel is using a new mechanism, the module mechanism: Many functions are contained within the module, you can use Insmod to hug it when you need it, load it dynamically into the kernel, and use Rmmod to kick it off when you don't need it. This makes the kernel core very small and can load and replace modules without reboot when running.

Secondly, we should pay attention to the understanding of the equipment model. In fact, starting from the 2.6 kernel, with the advent of the device model, the development of the drive is no longer a difficult problem, no exaggeration to say, understand the device model, and then look at the variety of drivers, you will find yourself standing at another height, so there is a kind of overlooking the feeling, like sister Feng overlooking the bosom friend and story, Comrade Han Feng the female subordinate. But it seems that most drive developers are unaware of the problem.

Finally, it is to develop the use of protocol spec, device datasheet, kernel Reference code to solve the problem of the habit, rather than a problem on the search for so-called cattle people to ask how to solve.

The middle of those content and the essence of the previous version of the It almost, do not post, ...

The previous three aspects of my personal sense of development drive need to be noted, and now I would like to say a practical example. A few days ago a netizen in his Csdn blog wrote an article, the name called to fudan_abc a letter, the letter said their own problems, I think a lot of people have such a similar problem, here we look at.

First say his personal situation: there is a certain Linux C Foundation, familiar with the Linux kernel/driver development environment to build and compile. Now want to be an I²C chip driver, the drive to run on the x86 platform.

The information at hand is:

1. The chip manual looked at a few times, a basic understanding of the resources above and his i²c address

2. Locate the corresponding. c files and. h files on the Linux + arm platform. However, the kernel source for the corresponding arm platform is not.

3. The code in the. c file is read over and the function name can be known.

Then start working on how to port this i²c chip onto the x86 platform. After encountering a number of column problems, such as the address of the i²c, and so on, I do not describe the details.

And then he went to consult some people.

Ask someone a: "In fact, it is very simple, you fill the driver structure is OK." I asked, "I'm not familiar with the processes and calls inside."

A: "You think of them as a black box," I: "can't imagine, how can I imagine? I want to see what the code inside is like. "A:" ... ". The result of A's advice can't solve my question: what should I do?

Then ask B:

B: "In fact, i²c transplant is the registration of the several functions, you want to see the kernel code implementation, the kernel is so big how can you figure out, I did so many transplant, sometimes even the chip manuals are not clear, directly prink bar code to the" I: "... "Unable to understand, speechless.

Actually here side of a and B said is also true, a lot of people write drive probably do this, but this is like writing hundreds of drivers can not say to understand the Linux driver, interview with the majority of people are in this situation, can answer what they did, But when it comes to some of the underlying issues, it's often not answered.

I think the first problem is the lack of curiosity, the curiosity to do technology should be the driving force, especially for the Linux kernel and drive, how much curiosity, your level will probably grow to how high.

Second, for the driver, for the 2.6 core, the important thing is to understand the device model, many people are putting the cart before the horse, a lot of specialized write-driven books do not pay attention to the understanding of the device model, only to deal with a type of protocol and device driver, even if write a 10,000 is only a relatively mature chip cooked some. Moreover, do not understand the device driver, do not write the driver when the time does not feel a lot of things hazy? This is also a very strange aspect that I personally think.

As I said in my previous device model article, understanding the device model has a feeling of looking down on all kinds of drivers. At this point you go to the specific type of protocol and device implementation, the context is very clear, such as you see the implementation of the I²c. This time is important is the agreement, the specific chip datasheet, plus look at the kernel of the existing I²c drive as a reference, is what I said drive development of the three pieces of treasure.

So if you want to do 2.6 of the driver, the key is to understand the next device model, the more abstract concept in the mind to visualize, and then to see the specific driver is better.

Linux kernel (17)-Learn Linux drive development efficiently