Do you want to know how to become a Linux kernel developer? Or your boss tells you, "Write a Linux driver for this device. "The purpose of this document is to describe the process you need to go through and instruct you how to work with the community to teach you all the knowledge you need to know for these purposes. This article also explains why the community works like this.
Almost all kernels are written in C, and some architecture-related components are written in assembly language. Mastering C language is essential for kernel development. An assembly language (any architecture) is not required unless you are preparing to develop the underlying architecture. Although the following books cannot completely replace the solid C Language Teaching and/or years of experience, they are still a good reference, if needed:
|
The kernel is written in the gnu c and GNU tool chains. Although it complies with the ISO c89 standard, it still uses some extensions not included in the standard. The kernel is a self-built C environment and does not rely on Standard C libraries. Therefore, some C language standards are not supported. Division and floating point number of any long type are not allowed. Sometimes it is hard to understand the kernel's assumptions about the toolchain and expansion it uses, and unfortunately there is no absolute reference to them. For more information, see the GCC info page ('info GCC.
Remember that you are trying to learn how to work with an existing development community. This is a group of people with complex components. They have high standards for code, style, and steps. These standards are time tested.
They found that following these standards is the best choice for such a large-scale and geographically dispersed team. Try to learn as much knowledge about these standards as possible in advance, because they all have good documentation; do not expect others to follow your or your company's approach.
Legal issues
The Linux kernel source code is published according to GPL. See the copying file under the source code tree to obtain details about this license. If you have any questions about this license, please contact your attorney and do not ask in the Linux Kernel email list. People in the email list are not lawyers and you should not rely on their interpretation of legal issues.
For more information about GPL, see:
Http://www.gnu.org/licenses/gpl-faq.html
Document
The Linux kernel source code tree contains many documents that are invaluable for learning how to communicate with the kernel community. When a new feature is added to the kernel, we recommend that you add the document explaining this new feature to the kernel. If a kernel change causes a kernel change to the user space interface, we recommend that you send this information or a manpage patch that explains the change to the maintainer mtk-manpages@gmx.net on the manual page.
Here is a list of files to be read in the kernel source code tree:
Readme
This file briefly introduces the background of the Linux kernel and describes what needs to be done to configure and compile the kernel. Start from here.
Do ***** entation/changes
This file describes the list of various software required for successful compilation and running of the kernel.
Do ***** entation/codingstyle
This file describes the Linux kernel code style and some reasons behind it. All new code must comply with the guidelines in this document. Most maintainers only accept patches that comply with these rules. Many users only check the correct code.
Do ***** entation/submittingpatches
Do ***** entation/submittingdrivers
These files detail how to successfully create and send a patch, including (but not limited ):
-Email content
-Email format
-Who to send
Compliance with all these rules does not guarantee success (a detailed check of content and style is required for all patches), but failure to comply with these rules will certainly fail.
Other good articles on how to create patches include:
"The Perfect patch"
Http://www.zip.com.au /~ Akpm/Linux/patches/stuff/tpp.txt
"Linux kernle patch submission format"
Http://linux.yyz.us/patch-format.html
Do ***** entation/stable_api_nonsense.txt
This file explains the reasons for conscious decisions-not using stable APIs in the kernel-, including:
-Subsystem separation layer (for compatibility ?)
-Drive portability between operating systems
-Ease (or stop) the rapid changes in the kernel source code tree
This document is critical to understanding the development philosophy of Linux. It is also important to switch from development of other operating systems to development of Linux.
Do ***** entation/securitybugs
If you feel that you have discovered a security problem in the Linux kernel, follow the steps described in this document to remind kernel developers and help solve the problem.
Do ***** entation/managementstyle
This document describes how Linux kernel maintainers operate and why they do so. It is very important for anyone new to kernel development (or anyone interested in this topic.
Because it explains some common error concepts, it can solve the doubts about the unique behavior of kernel maintainers.
Do ***** entation/stable_kernel_rules.txt
This document describes the rules for the stable version of the kernel, and what to do if you want to make some changes to one of the versions.
Do ***** entation/kernel-docs.txt
A list of external documents about kernel development. If not found in the kernel internal document? For more information, see the list.
Do ***** entation/applying-patches.txt
This section describes what patches are and how to apply patches to different kernel development branches.
The inner core also has many documents that can be automatically generated from the source code. This includes a comprehensive description of the kernel's internal API and the rules on how to handle the lock. These documents are created in the do ***** entation/docbook/folder. In the kernel main source code tree, run the following command to create documents in different formats such as PDF, postscript, HTML, and manpage:
make pdfdocs |
Become a kernel developer
If you have no idea about Linux kernel development, you can look at the Linux kernelnewbies project:
Http://kernelnewbies.org
It contains a list of emails where you can ask any basic questions about kernel development (search for the archive before asking the question, which is likely to have been answered .) It also has an IRC channel where you can ask questions in real time. It also has many useful documents and is useful for learning about Linux kernel development.
This website has basic information about code organization, subsystems, and the current project (within and outside the code tree. It also describes some basic "Logistics" information, such as how to compile the kernel and how to install patches.
If you do not know where to start, but want to find some tasks to join the kernel development community, please take a look at the Linux kernel janitor project:
Http://janitor.kernelnewbies.org/
This is a good start. It describes some problems that need to be cleared and solved in the kernel. Working with the developers responsible for this project, you will learn how to bring your patches into the Linux kernel tree, and may indicate the future direction for you, if not.
If you already have a piece of code that you want to put in the kernel tree, but you need some help, then the kernel-Mentors project can help you. This is an email list, which can be found below:
Http://selenic.com/mailman/listinfo/kernel-mentors
Before you make any actual changes to the Linux kernel code, you must understand how the relevant code works. For this purpose, there is no better way than simply reading it (there are good comments in many difficult places), or even reading it with the help of a special tool. It is recommended that such a tool is the Linux cross-reference project, which can display the source code in a self-referenced, indexed web page. A very good latest kernel code repository can be found here: http://sosdg.org /~ Coywolf/lxr
Development Process
The Linux kernel development process currently includes some main kernel branches, and many proprietary kernel branches of different subsystems. They are:
-Main 2.6.x kernel tree |
2.6.x kernel tree
2.6.x kernel tree is maintained by Linus Torvalds and can be found in the pub/Linux/kernel/v2.6 directory of kernel.org. Its development process is as follows:
-When a new kernel is released, a two-week window is opened, during which time the maintainer can submit major patches to Linus, usually a patch already exists in the-mm kernel for a certain period of time. The Recommended Patch submission method is through git (more information about git can be found at http://git.or.cz/), but the common patch is also available-one RC1 kernel is released two weeks later, now, you can only add a patch that does not add new features to the kernel, because such a patch may affect the stability of the kernel. Note that an entire new driver (or file system) is acceptable at this time. As long as this change is self-contained and does not affect code other than it, there will be no risk of regression. After-RC1 is released, git can send patches to Linus, but these patches also need to be sent to a public email list for review.
-When Linus is confident that the current git (kernel code management tool) tree is in a sound state and sufficient for testing, a new-RC will be released. The goal is to release a new-RC kernel every week.
-This process will last until the kernel is considered to be available for release, and the entire process will last for about 6 weeks.
Andrew Morton's statement about Kernel release in the Linux-kernel mailing list is worth mentioning: "No one knows when a kernel will be released, because it is released based on the bug status that has been mastered, rather than a previously imagined timeline.
2.6.x.y-stable kernel tree
The kernel with four numeric versions is the-stable kernel. They contain relatively small and important corrections. These corrections target security issues or major regression found in a given 2.6.x kernel.
This version is recommended for users who want to use the latest stable kernel and are not interested in testing, development, and experiment versions.
If 2.6.x.y is not available, 2.6.x kernel of the highest version is the current stable kernel.
2.6.x.y is maintained by the "stable" team and released once a week.
The file do ***** entation/stable_kernel_rules.txt in the kernel tree describes what changes can be accepted by the-stable tree and how the publishing process works.
2.6.x-Git patch
These are the daily snapshots of the Linus kernel tree managed in the GIT repository. These patches are released once a day, representing the current status of the Linus tree. They are more experimental than the-RC kernel, because they are automatically generated, so that no one has ever taken a glance to check whether they are healthy.
2.6.x-mm kernel patch
These are experimental Kernel patches released by Andrew Morton. Andrew obtained the kernel trees and patches for all different subsystems, along with the patches pulled from the Linux-kernel mailing list, and integrated them. This tree is a place where new features and patches prove themselves. If a patch proves its value in-mm, Andrew or the subsystem maintainer will submit it to Linus for inclusion in the main kernel.
We strongly recommend that all new patches be tested in the-mm tree before being sent to Linus.
The kernel with this patch is not suitable for systems that require stability. Running them is more risky than running any other branch.
If you want to help with the kernel development process, test and use these kernels for release, and provide feedback in the Linux-kernel email list. If you find any problem, even if there is no problem.
In addition to all other lab-type patches, these Kernel patches are usually included in the modifications already included in the main-Git kernel at the time of release.
-The mm kernel does not have a fixed release plan, but some-mm kernels are usually released during each two-RC kernels release interval (1 to 3 are common ).
Subsystem proprietary kernel tree and patch
Developers of Different kernel subsystems publish their development tree so that others can see what is happening in Different kernel fields. These trees will be included in the-mm kernel release.
The following is a list of Different kernel trees:
Git tree: |
Report bug
Bugzilla.kernel.org is the place where Linux kernel developers track kernel bugs. We encourage users to report all bugs they have found in this tool. For details about how to use the kernel Bugzilla, see: http://test.kernel.org/bugzilla/faq.html
The reporting-bugs file in the source code directory of the main kernel has a template that reports possible kernel bugs and details what information kernel developers need so that they can track the problem.
Email list
As described in some of the above documents, most core kernel developers participate in the discussion of the Linux kernel email list. Details about how to subscribe to and unsubscribe to this list can be found here:
Http://vger.kernel.org/vger-lists.html#linux-kernel
This email list is archived in many places on the Internet. Use a search engine to search for these archives. For example:
Http://dir.gmane.org/gmane.linux.kernel
We strongly recommend that you search for the topics you want to ask in the archive before sending an email to the list. Many things have been discussed in detail. They are only recorded in the archive of the email list.
Many kernel subsystems also have their separate email lists, where developers perform their development work. View the maintainer file to find the mail list of these subsystems.
Many mailing lists are placed on kernel.org. You can find their information here:
Http://vger.kernel.org/vger-lists.html
Remember to observe good behavior habits when using these lists. The following URL has some simple guidelines on how to communicate with people on the mail list, although somewhat cheesy: http://www.albion.com/netiquette
If many people reply to your email, the recipient's CC list will become very long. If there is no reasonable reason, do not remove anyone from the CC list, or reply to the listed address only. You should get used to receiving the same letter twice, one from the sender, and one from the mail list. Do not add a special mail header to look good. People do not like this.
Remember to ensure the integrity of the context and attributes of your reply, and keep a message similar to "John kernelhacker wrote" at the top of your reply... ", write your reply between the quoted paragraphs, rather than at the top of the email.
If you add patches to your email, make sure they are plain text, as stated in do ***** entation/submittingpatches. Kernel developers do not want to process attachments or compressed patches. They want to evaluate each line of your patch. Only plain text meets this requirement.
Make sure that the email client software you are using does not destroy spaces and tabs. You can send an email to yourself, and then apply your patch to perform a test first. If not, fix your email program or change one.
Remember to show your respect for other subscribers.
Working with the community
The goal of the kernel community is to provide the best kernel possible. When you submit a patch to be included, it will be checked only by the technical authority in this field. So what should you expect?
-Criticism
-Comment
-Required changes
-Interpretation required
-Silence
Remember, this is part of bringing your patch into the kernel. You must be able to accept criticism and comments on your patch, evaluate it at the technical level, and then either make modifications to your patch, either provide clear and concise reasons to explain why changes should not be made. If you do not reply to your patch, wait a few days and try again. Sometimes, when the traffic is high, emails may be lost or forgotten.
What should you do:
-Expect your patch to be accepted without any doubt |
In a community that looks for the best possible technical solutions, there must be different opinions on how a patch works. You should adopt a cooperative attitude and be willing to change your opinions to adapt to the needs of the kernel. Or at least you are willing to prove that your point of view is valuable. Remember, mistakes are acceptable, as long as you are willing to work toward the right solution.
If the response to your first patch is only comments that require you to correct, this is normal. This does not mean that your patches will not be accepted, and these opinions are not for you. All you have to do is correct your patch and resend it.
Differences between kernel community and Enterprise Architecture
------------------------
The kernel community works differently from most traditional enterprise development environments. Here is a list that you can try to follow to avoid problems:
A good saying about the patch you submitted:
-"This can solve multiple problems ." |
The bad statement you should avoid:
-"We did this on AIX/PTx/Solaris, so it must be good ......" |
Another difference between the kernel community and most traditional software engineering work environments is that there is no face-to-face communication. One of the benefits of using email and IRC as the main form of communication is that there will be no discrimination based on gender or race. The Linux Kernel Operating environment accepts ladies and ethnic minorities, because your presence is only an email address. Internationalization also helps us achieve an equal working environment because you cannot determine the gender of a person based on his/her name. A man can be Andrea and a woman can be Pat. Most women who have worked on or expressed their opinions on the Linux kernel have a deep understanding of this.
For those who are not used to English, language barriers may cause some problems. A good grasp of the language can make your mind communicate more smoothly on the mail list. Therefore, we recommend that you check whether your mail content is meaningful in English before sending the mail.
Crack your patch
The Linux kernel community is reluctant to accept large segments of code, which is generally discarded immediately upon receipt. Your patches need to be introduced, discussed, and scattered into small, independent fragments. This is almost the same as what companies often do. Your proposal must be put forward early in the development process so that you can receive enough feedback about your work. This also makes the community feel that you are working with them, rather than using them as a place to dump your patches. However, please do not send more than 50 emails to the Mail list at a time. The number of your series of patches should always be smaller than this number.
The reason for removing the patch is as follows:
1) a small patch increases the chance of your patch being applied, because it does not need to spend too much time and effort to check its correctness. A patch with five lines, a maintainer only needs to take a second to glance and then apply the patch. However, it takes an hour for a 500-line patch to check for any errors (the required time is about exponential growth as the patch size ). Small patches make debugging easy when an error occurs. If a problem occurs, the minor patch can be canceled one by one, and the major patch is troublesome.
2) In addition to removing patches, you must rewrite and simplify your patches (or simply reorder them) before submission. This is also important.
There is an analogy made by the kernel developer Al Viro: "I want a teacher to correct assignments for a student in the mathematics department. The teacher does not want to see the students' attempts and failures before answering the correct answers. They want to see the most clear and optimal answer. A good student understands this and will not submit their intermediate results before getting the final answer. This is also true for kernel development. Defenders and reviewers do not want to see the thinking process behind the solution. They want to see a simple and elegant solution ."
Providing a beautiful solution and working with the community to discuss your unfinished work may be challenging to maintain a balance between the two. Therefore, you should participate in a development process as early as possible to get feedback to improve your work, but you still need to ensure that your patches are small, so that they may be accepted early, even if your work is still complete.
Note that if your patch has not been completed and you still need to modify it, do not submit it.
Prove your changes
In addition to cracking your patches, it is important for the Linux community to understand why they want to add this change. New features must be validated and useful.
Write a document for your changes
When you submit a patch, pay special attention to what you say in your email. This information will be the changelog information for this patch and will be retained so that everyone can see it at any time. It must fully describe this patch, including:
|
For details about what the process looks like, see the changelog section in this document: "The Perfect patch"
Http://www.zip.com.au /~ Akpm/Linux/patches/stuff/tpp.txt
It is sometimes difficult to do all these things. It may take several years to fulfill these requirements perfectly. This is a process of continuous development and requires a lot of patience and determination. But don't give up. This can be achieved. Many people have already done this, and everyone has gone through this stage.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
