At a recent meeting of Linux Kernel Plumbers, which took place in Lisbon, Portugal, the typical testing automation for the Linux kernel was discussed. Leading Linux developers have teamed up to put effort into a solid testing framework: KernelCI. Now at Open Source Summit Europein Lyon, France, KernelCI becomes a project of the The Linux Foundation and receive the necessary investments and resources. First of all, do you really know what Linux, if it is just a kernel? Check out below the video Gabriel channel Tux's lair, addressing the subject.
Going further into this subject, see The Linux Foundation's official definition. I bet a lot will be demystified, coming from the very foundation that holds Linux, check out the article by clicking here.
Linux Kernel Development
Currently the Linux kernel is developed by a gigantic community made up of individuals, non-profit organizations, various companies and potential contributors. The method used to organize the project by Linux Kernel Mailing List (LKML). Let's say it's a huge email list, where developers interact with each other and suggest changes and implementations in the code. However, this form is not always one of the best for various tasks, patch issues are a good example given by Russel currey, one of the Linux kernel developers, explaining: (Unlike a project based solely on GitHub or GitLab), where a pull request contains all the information necessary to merge a group of changes; An email containing, say, patch 7/10, has no such context. It is almost impossible to know from an email message if a patch series has been merged, rejected or replaced. In general, mailing lists simply do not have the same level of metadata as contemporary project hosting sites and this makes the Continuous Integration (CI) problem even more difficult.
In this context comes KernelCI, initially designed to aid Linux testing on a very wide range of hardware. Because the tests were performed on a very limited and specific number of hardware. Basically the developers performed tests on their own equipment. Thus certainty of proper operation was ensured for the most common and popular hardware on the market, otherwise it was quite likely that no testing was performed on specific equipment.
Greg Kroah-Hartman, maintainer of the stable version of Linux, explains:
Linux runs everywhere and on so many different hardware, but the tests on them were minimal. Most people were just testing the few things they cared about. So we want to test it with the same hardware as us. Could you ensure that we really support all of the hardware we claim to support? .
Plans for using KernelCI go beyond implementing automated hardware testing. As well explained, Kevin Hilman, his co-founder and senior engineer at BayLibre in a talk at Open Source Summit Europe:
We met at Linux Plumbers. One of the big problems we have now is that we have six or seven different code testing projects that sent reports to kernel developers and maintainers. This was getting really annoying, so we came together and said, 'choose one to use as a framework', so we agreed to KernelCI, so we will all work together so as not to duplicate our efforts and results..
After effectively consolidating the new KernelCI, not only testing on different hardware will be performed. Like, its goal is to unify the different types of tests in the Linux kernel. The current weakness of the email discussion model for dealing with patches will be solved with a single place to store, view, compare and track the results of the numerous tests.
Image – Davide Boscolo
According to KernelCI Vice President for Business Development and Open Source Consulting Collabora, Guy lunardi, Since Linux has become crucial to society, it is essential to get comprehensive testing coverage of the Linux kernel. Applying the open source philosophy to the test, the architecture distributed by KernelCI allows the entire kernel community to collaborate around a single upstream Continuous Integration (CI) system..
Linux has become so relevant and essential to today's technology landscape that efforts to leverage its qualities and remedy its shortcomings are commonly developed and implemented. However, its use transcends barriers and its action encompasses a multitude of solutions in the market. Now with this automation system, KernelCI, Long Time Support (LTS) versions will now encompass a larger number of equipment and known issues. Hardware malfunction problems will no longer exist, or will decrease dramatically. This will improve the quality, stability and maintainability of the Linux kernel. In the end, an entire community will benefit.
What do you expect with such changes? Do you have any hardware that doesn't work fully on Linux?
Join our community Diolinux Plus, stay on top of news and share your opinions.
Until the next post, I wait for you here on the blog Diolinux, SYSTEMATICALLY!
See an error or would you like to add any suggestions to this article? Collaborate, click here.