2.6.39 released-Recent kernel development experiences

Linux Kernel 2.6.39 has finally been released. It takes a long time from RC1 to rc7. This is a memorable kernel version. Of course, it is only a memorable kernel version for me. Starting from 39-rc1, I decided to officially participate in kernel development. I have not been familiar with several format errors since the beginning, later I changed several function errors and wrote comments for the driver's core. I made a little progress and became more and more professional. It can be said that the road to making contributions to open-source is from the 39 version, which is memorable.

Actually, I have written about it before. I used to think that the kernel is a sacred thing. I can only read it and read it in a way that is God-oriented every day, I never thought of changing a sentence or a sentence in the past. I don't want to think about it. I think it is totally impossible. However, the progress of one year's work after graduation is really too great, in school, there is always such a thing every day, such a thing, such a job, such a job, in fact, the real peace of mind to see the code is not much time, sometimes easy to get dry, there is no big piece of time to study one thing, and during the working period, I was originally working on the Linux driver, and every day I was doing what I liked, looking at your favorite code, even though it is sometimes broken by some tough things, the overall focus is on it. Although there is some time to work, it is a little simple. After all, sometimes the driver is used, but some board devices are added. Sometimes I may have watched a module for several days and changed several lines during the change, you can also change several parameters. However, what is important is not the result. It is not the operation of the device but the normal operation, but the understanding of the device and the understanding of the driver, understanding of driver core and understanding of the entire Linux kernel system. So sometimes, I have worked for the same period of time and have done the same job. Some people have done well and some have done badly. In addition, people get different gains from the same thing.

For example, if you want to make a simple button driver or touch screen driver, you can follow the code added by the predecessors and change it to make it work. OK, the work is finished, the next step is the same. In the end, what is this? How does it work? If it is no longer enough, you will feel that work is not fun and meaningless.

On the contrary, after such a device works, you can further look at how it works, how the driver core drives them, and how the input core code is implemented, how does this layer-by-layer core Code make it easy for you to write a device driver? All of them understand that when other input device drivers are used, even may be comfortable with other device drivers, because you understand the input core and the driver core, over time, you may be able to optimize the entire system.

This is my understanding. In my daily work, I often try to understand it more deeply when I am working on a simple module, which increases the pleasure of my work. Congratulations.

In addition, on the premise of understanding deeply, I think we need to have a heart to contribute to open-source, although sometimes there will also be a private heart, because I watched my patch be applied, there will also be some little vanity, a sense of accomplishment, of course, this is also appropriate, without their own psychological satisfaction, without a sense of accomplishment, there is no motivation. Like a few days ago when I was doing a nand flash drive, I looked at mtd core and found a problem. I was very excited. I submitted a patch when I came back that night and was applied today, haha.

In the past, I always thought that it was not easy to identify many errors because of the size of the kernel. How can I easily propose a patch? In fact, it is very easy. When I look at it, of course, the premise is to read the code. when reading the code, you may find the error, and you may find the error during debugging. Maybe this bug will be adopted after you fix it.

For kernel development, I think it is necessary to be passionate. Sometimes I find a bug and I will pick up the patch in the middle of the night. Sometimes I am afraid that someone else will fix the bug first, this is a passionate part. In the mail queue, some are great guys who submit patches for the kernel day and night to learn from and learn from them.

Without knowing it, I went far. I wanted to talk about the 39 kernel. Yesterday, linus added 39 tags, which means 39 was officially released, then I sent an email saying that I will go to Japan to participate in the activity in the next two weeks. 39 won't be able to delay any more. I 'd like to send a rc8, but I 'd like to start 39 first and then open the merge window of 40, it is hoped that there will be no major trouble before coming back. In this case, 39 is released. It doesn't sound so sacred, haha.

Originally, this article was intended to write an experience of sending a patch today. It is only now written as PS, haha.

The day before, I sent a message about drivers/mtd/mtdcore. c's patch, sent two, one applied, and the other none. Artem says the second won't be able to merge in his l2 tree, because the proc function has been rewritten by others, I went to his tree and looked at it. I found that my patch was sent based on the linus tree. It was very outdated, then I want to clone his l2 tree and change it to another patch, but it is too difficult to clone a tree, so I took the file. Then:

1 mkdir temp_kernel
2
3 cd temp_kernel
4
5 git init
6
7 mkdir-p drivers/mtd/
8
9 cp mtdcore. c temp_kernel/drivers/mtd/
10
11 git add *
12
13 git commit-m "init"
14
15 vi temp_kernel/drivers/mtd/mtdcore. c #.
16
17 git diff # Check whether the change is correct
18 git commit-a # write notes
19
20 git format-patch-s-1
21
22 git send-email -- from "Wanlong Gao <wanlong.gao@gmail.com>" -- to "Artem *** <mail>" -- cc "linux-kernel@vger.kernel.org" 0001 -****

In this way, the patch is changed to the Linus tree directly, which is convenient and convenient, saving the trouble of cloning the entire tree, because there are too many trees for each maintainer. If we clone them, we need to pull them every day before the change, which is an edream. This is a good method, haha. You can take a look at the patch.

Off the topic: After the 39 kernel was released yesterday, the 40 window was opened today, and a pull was like a madman. At night, I came back to update the Linus tree and updated the code of two MB faster, crazy kernel hackers.

Well, it's almost written. It's a little tricky. You'll see it later.

By the way, yesterday, Wu Da threw his shoes at Fang Binxing, which was really amazing. Many its' anger...