Shulou(Shulou.com)06/01 Report--

This article mainly introduces "why Linux kernel maintenance will not fail". In daily operation, I believe that many people have doubts about why Linux kernel maintenance will not fail. The editor has consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubt of "why Linux kernel maintenance will not fail". Next, please follow the editor to study!

The just released Linux kernel 5.8 RC has more than 14000 commit, about 800,000 lines of new code, and about 100 new contributors. You know, it's only been about 2 months since the official version 5.7 was released. Steven Rostedt, a maintainer of the Linux kernel, believes that it is probably because the COVID-19 epidemic has made it difficult for many people to travel, so everyone is able to do more work than usual during this period.

Rostedt said that from the perspective of an experienced Linux kernel contributor and maintainer, what is particularly shocking about the 5.8 RC release is not its size, but that its unprecedented scale does not bother those who are maintaining it. "I think it's because Linux has a better workflow than any software project in the world."

What does it mean to have the best workflow? For Rostedt, this boils down to a series of basic rules that Linux kernel developers have established over time to enable them to continuously develop Linux kernel projects on a large scale and reliably. From the perspective of a senior maintainer of the Linux kernel, Rostedt shares with us how the huge Linux kernel project has worked methodically over the past 30 years.

The first key factor is Git.

First of all, let's look at the history of the Linux project. In the early days of the project (1991-2002), patches could only be sent directly to Linus Torvalds. Specifically, Linus gets patches from the project's child maintainers, who get patches from other code contributors. As the Linux kernel gets bigger and the code becomes more complex, they soon find that everything becomes difficult to extend and track, and the project will always be at risk of merging incompatible code.

This led Linus to explore various version management tools, including BitKeeper. BitKeeper is one of the earliest methods of distributed version management. Other version management systems usually use check-out / modify / check-in protocols, while BitKeeper provides copies of the entire repository to everyone and allows developers to send out their changes for merging. Linux briefly adopted BitKeeper in 2002, but stopped using the tool in 2005 because it was proprietary and was not considered to be in line with the community's belief in open source work. Looking for alternatives, Linus disappeared for a while and came back with git, which became a more powerful distributed version management system and the first important instantiation of the management process. With the advent of Git, Linux development still works well today.

Rostedt lists seven important basic principles that revolve around Git in the Linux kernel workflow.

Seven basic principles: commit can only do one thing at a time

The central principle of Linux is that all changes must be broken down into small steps-- you can only do one thing per commit. This does not mean that every commit has to be small, such as making a simple change to the API of a function used in thousands of files can make the change large, but still acceptable, because it is a change for a single task. By always following this principle, project maintainers can more easily identify and isolate any problematic changes without affecting other functionality.

Commit cannot break the build

Not only should all changes be broken down into as small variables as possible, but also the kernel should not be destroyed. That is, each step must be fully functional and does not cause degradation. This is why changes to the function prototype must also update each file that calls it to prevent build interruptions. Therefore, each step must work as a separate change, which brings us to the next point:

All the code is divided into two parts.

If an error is found at some point, you need to know which change is causing the problem. In essence, dichotomy is an operation that allows developers to find the exact time when all errors occur.

To do this, go to the node where the last known working commit is located and know that the first commit is corrupted, and then test the code at that point. If possible, proceed to the next node; if not, return to the higher node. In this way, developers can isolate the problem-causing commit from thousands of possible commit in more than a dozen compilations / tests. Git can even help automate the process through the git bisect feature.

Importantly, this only works well if the developer follows the previous rules: only one thing per commit. Otherwise, you won't know which of the many changes in commit is causing the problem; if commit destroys the build and prevents the entire project from starting properly, and the bisector happens to fall on that commit, you won't know whether to test up or down next, because they all have problems. This means that you should never write a commit that depends on a future commit, such as calling a function that does not yet exist, or changing the parameters of a global function without changing all callers in the same commit.

Never rebase public branches

The Linux project workflow does not allow rebase others to use any public branches. Because after these common branches of rebase, the re-referenced commit will no longer match the same commit based on the original repository. In the hierarchical structure of the tree, the common trunk, which is not a leaf, cannot be rebased, otherwise it will destroy the downstream branches in the hierarchy.

Git merge correctly

Other version management systems are nightmares of merging code from different branches, which are often difficult to figure out and require a lot of manual work to resolve. The structure of Git makes it easy to do this, so the Linux project directly benefits from it. This is an important reason why the size of version 5.8 is not important. During the 5.8-RC1 release cycle, there were an average of 200 commit per day and inherited 880 mergers from version 5. 7. Some defenders have noticed the increased workload, but still do not feel too much pressure or lead to burnout.

Keep well-defined commit logs

Unfortunately, this is probably one of the most important principles that many other projects ignore. Each commit must be independent, which should also include logs corresponding to that commit. The kernel contributor must explain in the commit log of the changes to let everyone know everything related to the changes being made. Rostedt mentioned that some of his own most lengthy and descriptive change logs are often submitted for single lines of code because these single-line code changes are very subtle bug fixes and the code itself contains very little information. So the less code you change, the more detailed the log should be.

After a few years of a commit, few people will remember why the change was made in the first place. The blame function of Git can display the modification records of these codes. For example, some commit may be very old, or you may need to remove a lock or make changes to some code without knowing exactly why it exists, so you can use git blame to view it. A well-written code change log can help determine whether the code can be deleted or how to modify it. Rostedt said: "several times I was happy to see the detailed change log on the code because I had to delete the code, and the description of the change log let me know that I could do so."

Continuous testing and integration

The final basic principle is continuous testing and continuous integration during development. Before sending an commit request to the upstream, the developer tests each commit. The Linux community also has a mirror called Linux-next, which extracts all changes made by maintainers on specific branches of their repository and tests them to ensure that they are integrated correctly. Linux-next runs the testable branch of the entire kernel very efficiently, which will be used in the next release. Linux-next is a public repository, and anyone can test it, which often happens-- people now even publish error reports about the code in Linux-next. In fact, code that has been in Linux-next for a few weeks is almost certain to end up in the mainline release.

The gold standard of the software development industry

All of these principled regimes enable the Linux community to release incredibly reliable code on such a large scale (a regular nine-week iteration cycle) (an average of 10000 commit per version and more than 14000 commit in the last version).

Rostedt points out that another factor contributing to the unprecedented success of the Linux project is the culture of their community. There is a culture of continuous improvement within the Linux kernel community that enables them to adopt these practices in the first place. At the same time, they also have a culture of trust, "We have a clear way in which people can contribute and prove over time that they are willing and able to advance the project." this will build a network of mutual trust that is critical to the long-term success of the project. "

Rostedt believes that kernel developers have a heavier responsibility than any other project. " In the inner nuclear layer, we have no choice but to follow these practices. Because all other applications run on top of the kernel, any performance problems or errors in the kernel will cause performance problems or errors in upper-level applications. We must deal with the errors in the kernel perfectly, otherwise, the whole computer system will be damaged. We are very concerned about every error, because the risk of errors in the kernel is high, and this way of thinking allows us to serve any software project well. "

Upper-level applications will crash because of errors, which may annoy users, but the risk is not high. The possible consequence of kernel errors is to make everything on the computer go wrong and take a huge risk.

At this point, the study on "why the maintenance of the Linux kernel will not collapse" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.