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

This article mainly shows you "what the Linux kernel testing life cycle is like", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and learn this article "what the Linux kernel testing life cycle is like."

Start with a change

Every exciting feature, improvement, and bug in the kernel begins with a change proposed by the developer. These changes appear in a large number of mailing lists in various kernel repositories. Some repositories focus on certain subsystems in the kernel, such as storage or networking, while others focus on more aspects of the kernel. When a developer proposes a change or patch set to the kernel, or when a maintainer makes changes in the repository itself, the CKI project takes action.

The triggers maintained by the CKI project are used to monitor these patch sets and take action. Software projects such as Patchwork make this process easier by integrating multiple patch contributions into a single patch series. The patch series goes through the CKI system as a whole, and individual reports can be issued for the series.

Other triggers can monitor changes in the repository. Triggers when kernel maintainers merge patch sets, restore patches, or create new tags. Testing these key changes ensures that developers always have a solid baseline that can be used as a basis for writing new patches.

All of these changes go into the GitLab CI pipeline and go through multiple phases and systems.

Prepare to build

First of all, prepare the source code to compile. This requires cloning the repository, typing the patch set recommended by the developer, and generating a kernel configuration file. These profiles have thousands of options for turning features on or off, and profiles vary widely from system architecture to system architecture. For example, a fairly standard x86x64 system may have many options available in its configuration file, but the s390x system (IBM zSeries mainframe) may have much fewer options. Some options may make sense on this mainframe, but they have no effect on consumer laptops.

The kernel is further converted to source code artifacts. This artifact contains the entire repository (patched) and all kernel configuration files required for compilation. The upstream kernel is packaged into a zip package, while the Red Hat kernel generates the source code RPM package for the next step.

Heaped compilation

Compiling the kernel converts the source code into code that the computer can start and use. The configuration file describes what to build, scripts in the kernel describe how to build it, and tools on the system (such as GCC and glibc) complete the build. This process will take some time to complete, but the CKI project needs to be completed quickly for four architectures: aarch74 (64-bit ARM), ppc64le (POWER), s390x (IBM zSeries), and x86. 64. It is important that we compile the kernel quickly so that there is no backlog of tasks and developers can receive feedback in a timely manner.

Adding more CPU can greatly increase speed, but each system has its limitations. The CKI project compiles the kernel in containers in OpenShift's deployment environment; although OpenShift can achieve high scalability, the number of CPU available in the deployment environment is still limited. The CKI team assigned 20 virtual CPU to compile each kernel. Four architectures are involved, which increases to 80 CPU!

Another speed boost comes from the ccache tool. Kernel development is progressing rapidly, but most of the kernel remains the same even between multiple releases. The ccache tool caches built objects (a small portion of the entire kernel) on disk during compilation. When you compile another kernel later, ccache looks for the unchanged parts of the kernel that you saw earlier. Ccache extracts the cached object from disk and reuses it. This speeds up compilation and reduces overall CPU usage. Now, the kernel, which takes 20 minutes to compile, is complete in less than a few minutes.

Test time

The kernel enters the final step: testing on real hardware. Each kernel uses Beaker to start on its native architecture and begins numerous tests to find problems. Some tests look for simple problems, such as container problems or error messages at startup. Other tests go deep into various kernel subsystems to find regression issues in system calls, memory allocation, and threads.

Large test frameworks, such as Linux Test Project (LTP), contain a large number of tests that look for troublesome regression problems in the kernel. Some of these regression issues may roll back key security fixes and test to ensure that these improvements remain in the kernel.

After the test is complete, the key step remains: reporting. Kernel developers and maintainers need a concise report that tells them exactly what works, what doesn't, and how to get more information. Each CKI report contains details of the source code, compilation parameters, and test output used. This information can help developers know where to start looking for solutions to the problem. In addition, it helps maintainers know when to keep the patch set for other viewing before the vulnerability enters the kernel repository.

These are all the contents of the article "what is the Linux kernel test life cycle?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.