How to participate in Linux kernel development

This article originates from the Hoto file under the document folder of the Linux kernel code.
Chinese translated version of Documentation/howto

If you had any comment or update to the content, please contact the
Original document maintainer directly. However, if you have a problem
Communicating in 中文版 You can also ask the Chinese maintainer for
Help. Contact the Chinese maintainer if this translation is outdated
Or if there is a problem with the translation.

Maintainer:greg Kroah-hartman <[email protected]>
Chinese Maintainer:li Yang <[email protected]>
---------------------------------------------------------------------
Documentation/howto's Chinese Translation

If you want to comment or update the content of this article, please contact the maintainer of the original document directly. If you use English
If the communication is difficult, you can also ask the Chinese version of the maintainer for help. If this translation is not updated in time or
Please contact the Chinese version of the maintainer.

Maintainer of the English version: Greg kroah-hartman <[email protected]>
Chinese version maintainer: Li Yang Li Yang <[email protected]>
Chinese translator: Li Yang Li Yang <[email protected]>
Chinese translator: Jong Triplex Chung <[email protected]>
Chen Qi Maggie Chen <[email protected]>
Cong Wang Cong <[email protected]>

The following is the text
---------------------------------------------------------------------

How to participate in Linux kernel development
---------------------

This is the ultimate secret to clean sweep about how to participate in Linux kernel development issues. It will guide you
Become a Linux kernel developer and learn how to work with the Linux kernel development community. It as far as possible not
Includes any technical details about kernel programming, but it will guide you to the right way to get that knowledge.

If any of the content in this article no longer applies, please send a patch to the file maintainers listed at the end of the text.


Entry
----

Do you want to know how to become a Linux kernel developer? Or the boss tells you to "write a Linux for this device."
Driver "? The purpose of this article is to teach you all the tricks of achieving these goals, which will describe what you need to
The process to go through and some tips on how to work with the kernel community. It will also attempt to explain the kernel community
Why this works.

Most of the Linux kernel is written in C, and some architecture-related code is used in assembly language. To
To participate in kernel development, you must be proficient in C language. Unless you want to develop the underlying code for an architecture, you
There is no need to understand (any architecture) assembly language. Although the books listed below cannot replace the solid C
Language education and years of development experience, but if necessary, as a reference is still good:
-"The C programming Language" by Kernighan and Ritchie [Prentice Hall]
C Programming Language (2nd Edition/New version) (Baowen Xu Li zhi) [mechanical industry Press]
-"Practical C Programming" by Steve Oualline [O ' Reilly]
"Practical C Language Programming (third edition)" (Guodahai) [China Electric Power Press]
-"C:a Reference Manual" by Harbison and Steele [Prentice Hall]
"C Language Reference manual (original book 5th edition)" (Chiu Jongpan) [Mechanical industry Press]

The Linux kernel was developed using the GNU C and GNU Toolchain. Although it follows the ISO C89 standard, it also uses some
There are no extensions defined in the standard. The kernel is a self-sufficient C environment and does not rely on the support of standard C libraries, so
Partial definitions in the C standard are not supported. For example, a long long type of large number division and floating-point operation will not allow
Use. Sometimes it's really hard to figure out the kernel's requirements for the toolchain and the extensions it uses, unfortunately
There are no clear references to explain them before. Please consult the GCC information page (using the "info gcc" command
Display) for some of this information.

Keep in mind that you are learning how to deal with existing development communities. It consists of a group of people of all stripes,
They have a high standard of code, style, and process. These standards are summed up in long-term practice,
Adapt to large, geographically dispersed development teams. They have been well organized into files, suggesting that you are developing
Learn as many of these standards as you can, and don't expect others to adapt to the way you or your company behaves.


Legal issues
--------

The Linux kernel source code is released under the protection of the GPL (general Public License). To understand this license
Please see the copying file under the source code home directory for details. If you have any further questions about it, please contact
Lawyers, instead of asking questions on the Linux kernel Mail group. Because the people in the Mail group aren't lawyers.
Look at their words with legal effect.

For FAQs and answers to the GPL, please visit the following links:
Http://www.gnu.org/licenses/gpl-faq.html


Document
----

A large number of documents are included in the Linux kernel code. These documents are for learning how to interact with the kernel community
inestimable value. When a new feature is added to the kernel, it is best to explain how to use this feature in the text
The file is also placed in the kernel. When changes are made to the interface of the user-oriented space, it is best to
or manual page (manpages) to [email protected] to the manual page (manpages)
The maintainers explain these changes.

Here are the documents you need to read in the kernel code:
Readme
The file briefly describes the background of the Linux kernel and describes how to configure and compile the kernel. of the kernel
The new user should start here.

Documentation/changes
The file gives a list of the minimum packages needed to compile and use the kernel.

Documentation/codingstyle
Describes the code style and rationale for the Linux kernel. All new code needs to comply with the rules defined in this document.
Fan. Most maintainers will only receive compliant patches, and many will only help check the style.
The code.

Documentation/submittingpatches
Documentation/submittingdrivers
These two documents clearly describe how to create and send patches, including (but not limited to):
-Email content
-Message Format
-Select recipient
Compliance with these rules does not guarantee a successful submission (as all patches require strict content and style
Censorship), but ignoring them almost means failure.

Other excellent documentation on how to generate patches correctly includes:
"The Perfect Patch"
Http://userweb.kernel.org/~akpm/stuff/tpp.txt
"Linux Kernel Patch submission format"
Http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt
The reason why the kernel deliberately does not include a stable kernel internal API, that is, does not include such a special
Of
-Subsystem middle tier (for compatibility?) ）
-Easy-to-migrate drivers between different operating systems
-Slow (or even block) rapid changes in kernel code
This document is essential for understanding the development philosophy of Linux. For the development platform from other operating systems
It is also important for people who transfer to Linux.

Documentation/securitybugs
If you think you've found a security issue with the Linux kernel, follow the steps in this document to
Remind other kernel developers and help solve this problem.

Documentation/managementstyle
Describes the working methods of kernel maintainers and their common characteristics. This is for new contact with kernel development (or
Curious) Because it explains a lot about the unique behavior of the kernel maintainer.
Widespread misunderstanding and confusion.

Documentation/stable_kernel_rules.txt
Explains the rules published by the stable kernel and how to put the changes into these versions.

Documentation/kernel-docs.txt
A list of external documents that contribute to kernel development. If you don't find it in the kernel's own documentation, you want to find
, you can view these documents.

Documentation/applying-patches.txt
A good introduction to what a patch is and how to hit it on a different kernel development branch

The kernel also has a large number of documents that are automatically generated from code. It contains a comprehensive introduction to the internal kernel APIs and how to
Proper handling of lock rules. The resulting document is placed in the documentation/docbook/directory. , including
PDF, Postscript, HTML, and manuals will be generated separately using the following different commands in the main source directory
Pages and other documents in different formats:
Make Pdfdocs
Make Psdocs
Make Htmldocs
Make Mandocs


How to become a kernel developer
------------------
If you know nothing about Linux kernel development, you should visit the "Linux kernel Novice" program:
http://kernelnewbies.org
It has a mailing list that can ask the most basic kernel development questions (be sure to remember before you ask questions)
Look for past messages and confirm if someone has answered the same question. It also has an access to
Real-time feedback on IRC chat channels, as well as a number of documents that are quite helpful for learning Linux kernel development.

The site provides a brief overview of the source code organization, subsystem partitioning, and ongoing projects (including kernel
and individually maintained). It also provides some basic help information, such as how to compile the kernel and make a fill
Ding.

If you want to join the kernel development community and help with some tasks, but can't find where to start, you can access
"Linux kernel Librarian" program:
Http://kernelnewbies.org/KernelJanitors
This is a very good starting point. It provides a relatively simple task list that lists the kernel code that needs to be re-
A place to be sorted or corrected. By working with developers who are responsible for this program, you will learn to patch
The fundamentals of integrating into the kernel. If you haven't decided what to do next, you may also get
The direction of the sexual guidance.

If you already have some ready-made code that you want to put in the kernel, you need some help to make them
The correct format. Please visit the "Kernel Mentor" program. This plan is designed to help you accomplish this goal. It
is a mailing list with the following address:
Http://selenic.com/mailman/listinfo/kernel-mentors

Before you actually modify the kernel code, it is necessary to understand how the code to be modified works. To achieve this
Purpose, there is no way to be more effective than reading the code directly (most tricks will have a corresponding comment), and
Some specially crafted tools can also help. For example, the "Linux Code cross-reference" project is a worthwhile
A particularly recommended Help tool, which displays the source code on pages with catalogs and indexes. One of the updates and
When the kernel source library, you can access the following address:
http://sosdg.org/~coywolf/lxr/


Development process
--------

The current Linux kernel development process includes several "main kernel branches" and many subsystems related to the kernel branch. This
Some of the branches include:
-2.6.x main kernel source tree
-2.6.x.y-stable Kernel source tree
-2.6.x-git Kernel Patch Set
-2.6.x-mm Kernel Patch Set
-subsystem-related kernel source tree and patch Set


2.6.x Kernel main source tree
-----------------
The 2.6.x kernel is personally maintained by Linus Torvalds (the creator of Linux). You can be in
Find it in the pub/linux/kernel/v2.6/directory of the kernel.org website. Its development follows the following steps
Sudden:
-Every time a new version of the kernel is released, the two-week integration window will be opened. During this period of time
Maintainers can submit large sections of the changes to the Linus, which are usually placed in the-MM kernel for several
A week. The preferred way to commit a lot of changes is to use the Git tool (the kernel's Code version management tool
, more information can be obtained at http://git.or.cz/), but the use of regular patches is also
Of
-Two weeks later the-RC1 version kernel was released. After that, only those that do not contain the stability of the entire kernel can
Patches for new features may be accepted. Note that a completely new driver (or file system) has
May be accepted after-RC1 because such modifications are completely independent and do not affect other code, so
There is no risk of a kernel setback. You can also use Git to submit patches to Linus after-rc1, but the
Some patches need to be sent to the appropriate public mailing list for comment.
-When Linus believes that the current git source tree has reached a reasonably sound state enough to be released for human testing
, a new version of-RC will be released. The plan is to publish a new version of-RC every week.
-the process continues until the kernel is considered to be stable enough, and the duration is probably
6 weeks.
-The following address tracks the list of regressions found in each-RC release:
Http://kernelnewbies.org/known_regressions

About Kernel Publishing, it's worth mentioning that Andrew Morton in the Linux-kernel mailing list:
"No one knows when the new kernel will be released because the release is based on a known bug.
, not according to a predetermined timetable. ”


2.6.x.y-stable (Stable version) kernel source tree
-----------------------------------
The kernel version number consisting of 4 digits indicates that the kernel is a-stable version. They contain versions based on 2.6.x
The relatively small and critical patching of the kernel, which addresses security issues or critical kernel regressions.

This version of the kernel is intended for those who expect to get the latest stable kernel and do not want to participate in the Beta dev version or
Users of the experimental version.

If there is no 2.6.x.y version of the kernel, then the latest 2.6.x version of the kernel is equivalent to the current stable
version of the kernel.

The 2.6.x.y version is maintained by the "stable" group (e-mail address <[email protected]>) and is generally isolated Zhou Fa
New version of the cloth.

The Documentation/stable_kernel_rules.txt file in the kernel source code specifically describes what can be stabilized
The type of modification the kernel accepts and the process of publishing it.


2.6.x-git Patch Set
----------------
The daily snapshot of the Linus Kernel source tree, which is managed by the Git tool (hence the name). This
Patches are usually updated daily to reflect the latest state of Linus's source tree. They are more than the-RC version of the kernel source
The tree is more experimental because the patch set is fully automated and there is no one to confirm whether it really
Sound.


2.6.X-MM Patch Set
---------------
This is a set of experimental kernel patches maintained by Andrew Morton. Andrew will all the subsystems of the kernel source
Pieced together with patches and added a lot of patches from the Linux-kernel mailing list. This one
The source tree is the testing ground for new features and patches. When the patch proves its value in the-MM patch set, Andrew
Or the maintainer of the corresponding subsystem will send the patch to Linus for integration into the main kernel source tree.

Before sending all new patches to Linus for integration into the main kernel source tree, we encourage you to first
The-mm is tested in the kernel source tree of the version.

These kernel versions are not intended to be run on systems that need to run stably, because running them is more than running any other
Kernel branches are more risky.

If you want to help with the kernel development process, try and use these kernel versions and
Linux-kernel provide feedback in the mailing list to tell everyone that you have a problem or that everything is OK.

Usually the-mm version of the patch set includes not only these additional experimental patches, but also the-git moderator source tree at the time of release
Changes in the.

The-mm version of the kernel does not have a fixed release cycle, but there are usually a few in between each of the two-RC releases
-MM version of the kernel (typically 1 to 3).


subsystem related kernel source tree and patch Set
----------------------------
A significant portion of the kernel subsystem developers will expose their own development source tree so that others can understand the internal
What is happening in different areas of the nucleus. As mentioned above, these source trees are integrated into the-MM version kernel.

The following is a list of some of the kernel source trees currently available:
The source tree managed by git:
-Kbuild Development source tree, Sam ravnborg <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

-ACPI development source tree, Len Brown <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

-Block device Development source tree, Jens axboe <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

-DRM development source tree, Dave Airlie <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

-IA64 development source tree, Tony Luck <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

-ieee1394 Development source tree, Jody McIntyre <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

-InfiniBand Development source tree, Roland dreier <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

-Libata Development source tree, Jeff Garzik <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

-Network Driver Development source tree, Jeff Garzik <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

-PCMCIA Development Source tree, Dominik Brodowski <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

-SCSI development source tree, James Bottomley <[email protected]>
Git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

Use quilt to manage patch sets:
-USB, PCI, driver Core and i²c, Greg Kroah-hartman <[email protected]>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
-X86-64, part i386, Andi Kleen <[email protected]>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/

Other kernel source trees can be in the http://git.kernel.org list and in the maintainers file.
Found it.

Report a Bug
-------

Bugzilla.kernel.org is a Web site that Linux kernel developers use to track kernel bugs. We encourage the use
The user reports all bugs found in this tool. For details on how to use kernel Bugzilla, please visit:
Http://test.kernel.org/bugzilla/faq.html

There is a good template in the Reporting-bugs file in the main source directory of the kernel. It guides how users report
The kernel bugs and what information needs to be provided to help kernel developers find the root cause of the problem.


Using Bug reports
-----------

The best way to practice kernel development skills is to modify bugs reported by others. You can not only help the kernel to change
More stable, you can learn how to solve practical problems to improve your skills, and let other development
The person who feels your presence. Modifying bugs is the best way to win praise from other developers, because not many
People like to waste their time modifying the bugs reported by others.

To try to modify a known bug, please visit the http://bugzilla.kernel.org URL. If you want to get
Latest bug notifications, you can subscribe to the Bugme-new mailing list (only new bug reports are sent here)
or subscribe to the Bugme-janitor mailing list (all Bugzilla changes will be sent here).

Https://lists.linux-foundation.org/mailman/listinfo/bugme-new
Https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors


Mailing list
--------

As described in the previous document, most backbone kernel developers have joined the Linux kernel mail column
Table. Details of how to subscribe to and unsubscribe from the list can be found here:
Http://vger.kernel.org/vger-lists.html#linux-kernel
There are many places on the web that have this mailing list archive (archive). You can use search engines to find these
Archive. Like what:
Http://dir.gmane.org/gmane.linux.kernel
Before sending a letter, we strongly recommend that you search the archive for the question you want to discuss. Many have been detailed
The issues discussed can only be found in the archive of the mailing list.

Most of the kernel subsystems also have their own separate mailing lists to coordinate their development efforts. From
You can find the mailing lists for different topics in the maintainers file.

Many mailing lists are hosted on kernel.org servers. The information for these lists can be found here:
Http://vger.kernel.org/vger-lists.html

When you use these mailing lists, keep in mind that you have a good habit of behaving. The following links are provided with these columns
Table (or any other mailing list) to communicate some simple rules, although the content is a bit impostors.
http://www.albion.com/netiquette/

When a lot of people reply to your message, the CC list of the message becomes very long. Please do not send anyone from CC
list, unless you have enough reason to do so. And don't just reply to the mailing list. Be accustomed to the same
A message is received two times (one from the sender, one from the mailing list) and not an attempt to add a
Strange headers to solve this problem, people will not like.

Remember to keep the context and source of the content you reply to. At the top of your reply message, keep "xxx ..."
These few lines. Add your comments between the referenced paragraphs and not at the top of the message.

If you have patches in your mail, make sure they are plain text that you can read directly (such as
Documentation/submittingpatches in the documentation). Kernel developers do not want to encounter attachments
Or a patch that has been compressed. This is the only way to ensure that they can comment on each line of your code directly. Please make sure
The Mail sender you use does not modify spaces and tabs. A preventative test method is to first mail
Send it to yourself and then try it yourself if you can hit the patch that you received. If the test is unsuccessful, please
Adjust or replace your mail sender until it works correctly.

In summary, please respect other mailing list subscribers.


Working with the core community
----------------

The goal of the kernel community is to provide the perfect kernel. So when you submit a patch you expect to be accepted into the kernel
, its technical value and other aspects will be reviewed. So what would you possibly get?
-Criticism
-Reviews
-Request Modification
-Requirement to prove the need for modification
-Silence

Keep in mind that these are the normal conditions for putting patches into the kernel. You must learn to listen to criticism and comment on patches,
Evaluate them from a technical level, and then either rewrite your patches or simply argue that the changes are unnecessary
Of If your email doesn't get any response, please try again in a few days, because sometimes the letters will submerged
Not in the boundless letter sea.

Things you should not do:
-Expect your patches to be accepted without any doubt
-Turn Your Face
-Ignore comments from others
-Resubmit without making any changes as requested by others

In a community that strives to pursue the best technology, there is always a difference in how many benefits a patch can have.
Solution. You have to be cooperative and willing to change your point of view to adapt to the style of the kernel. Or at least
Be willing to prove that your ideas are valuable. Remember that making mistakes is permissible, as long as you are willing to move towards the right
Program to try.

This is normal if your first patch comes with a bunch of modification suggestions. This does not mean that your patch
Will not be accepted, it does not mean that someone is against you. All you have to do is correct all the questions you ask and then re-send
Send you a patch.

The difference between the kernel community and the corporate culture
------------------------

The working mode of the kernel community is not the same as that of most traditional company development teams. The following examples
can help you avoid certain problems that may occur:
It would be helpful to introduce your proposed amendment in these words:
-it solves multiple problems at the same time
-It deleted 2000 lines of code
-This is the patch, it has explained what I want to explain
-I tested it on 5 different architectures .....
-This is a series of small patches used to ...
-This modification improves the performance of ordinary machines ...

This should be avoided by saying:
-That's what we do in Aix/ptx/solaris, so it's definitely good.
-I've been in this line for 20 years, so ...
-To make money for our company, consider this.
-This is what we need for our corporate product line
-Here is a 1000-page design document describing my point of view
-This is a 5000 line patch used to ...
-I rewrite the current mess of code, this is ...
-I was prescribed a deadline, so this patch needs to be accepted immediately

Another core community that differs from the software development teams of most traditional companies is the inability to face
Flow. One of the benefits of using e-mail and IRC chat tools as a primary communication tool is gender and racial discrimination
will be less. The Linux kernel's working environment is more receptive to women and minorities because everyone in the eyes of others
is just an email address. Internationalization also helps to achieve fairness, because you can't judge people by their names.
of gender. Men may be called Li Li, women may also be called Wang Gang. Most have worked on the Linux kernel
And the women who expressed their views gave positive comments on the experience of working on Linux.

For some people who are not accustomed to using English, language can be a problem-causing obstacle. In the mailing list
It is necessary to have a good grasp of the language in order to correctly express your ideas, so it is advisable to check your email before sending
Is it correct to write in English?


Split modification
--------

The Linux kernel community does not like to receive large sections of code. Modifications need to be properly introduced, discussed and
Split into separate small segments. This is almost entirely contrary to the habits of the company. Your idea should be in the development of the most
The start stage lets you know so that you can get feedback on the development you're working on in time. This
It also makes the community feel that you are collaborating with them, rather than just treating them as dumping new features.
In any case, you should not send 50 letters to the mailing list at once, your patch sequence should never be used
So much.

The reasons for unpacking the patch are as follows:

1) Small patches are more likely to be accepted because they do not require much time and effort to verify their correctness.
A 5-line patch may be accepted after the maintainer has glanced at it. And the 500-row patch
It takes a few hours to review its correctness (the time required increases exponentially with the size of the patch).

When something is wrong, a small patch can make debugging very easy. One by one a patch backtracking
It will be much easier to dissect a big patch (the patch destroys something else) than to carefully parse it.

2) It is important not only to send small patches, but to rearrange, simplify (or simply rearrange) before committing.
Patches are also important.

Here's a metaphor for the kernel developer Al Viro to play:
"Imagine a teacher is correcting math homework for the students." The teacher didn't want to see the students
The attempt to correct the solution and the resulting error. What he wants to see is the cleanest, most elegant.
Answer. Good students understand this and will never submit an interim solution before the final solution. ”

The same is true for kernel development. Defenders and reviewers do not want to see a person's thinking when solving a problem
Test process. They only want to see simple and elegant solutions.

By giving first-class solutions and collaborating with the community to discuss unfinished work, it seems
It's hard to find a point of balance. So it's best to start collecting feedback as early as possible to help you improve;
Make sure that the changes are broken into small chunks so that the entire project is ready to be included in the kernel, one of the
May be received first.

It is important to understand that this is unacceptable: try to submit unfinished work to the kernel, and then find time to fix it.
Complex.


The necessity of proving the change
----------------
In addition to splitting patches into small chunks, it's important to let the Linux community know why they need to be modified.
You have to prove that the new features are needed and useful.


Record modification
--------

When you send a patch, you need to pay special attention to the contents of the message body. Because the information here will be done as a supplement
(ChangeLog), will be reserved for everyone to check. It needs to completely describe the patch,
Including:
-Why this modification is required
-The overall design of the patch
-Implementation Details
-Test results

To find out what it should look like, check out the "ChangeLog" section in the following document:
"The Perfect Patch"
Http://userweb.kernel.org/~akpm/stuff/tpp.txt


These things are sometimes difficult to do. It can take years to be perfect in every way. This is
A process of continuous improvement, it requires a lot of patience and determination. As long as you do not give up, you can certainly do it.
A lot of people have done it, and they've all stood at the same starting point as you are.


---------------
Thanks to Paolo Ciarrocchi allow the "Development process" section to be based on the articles he wrote
(http://www.kerneltravel.net/newbie/2.6-development_process), thank Randy
Dunlap and Gerrit Huizenga perfected the list of what should and should not be said. Thanks Pat Mochel, Hanna
Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer,
Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian
Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael
Kerrisk and Alex Shepard's review, advice and contributions. Without their help, this document is not
Can do.



Maintainer of the English version: Greg Kroah-hartman

How to participate in Linux kernel development (RPM)