Linux 15 Kernel repository, Kernel collaboration method, subscribe to mailing list, submit PATCH

kernel.org

  kernel.org is the most important distribution site of the Linux kernel source code, mainly including infrastructure such as the kernel.org website and the Git repository. Its primary role is to host source code repositories used by Linux kernel developers and maintainers of various Linux kernel distributions. In addition, it is the control center for collaborative development of the Linux Kernel.

  Linux Kernel's source code hosting operation is different from those open source software that use public online code hosting platforms such as GitHub and GitLab (accounting for the majority, such as nodejs , Python ), and also different from those that use their own dedicated hosting platforms built with GitLab and Gitea The open source software (few, such as U-Boot ) is different from the open source software that only provides source code in tar package (very few, such as ARM GNU Toolchain). One of the important reasons is that it is difficult for these online platforms to support such a large-scale project as the Linux Kernel.

  At present, Linux Kernel uses its own Git code hosting platform to manage the Linux Kernel source code. Each part has its own independent source code warehouse, which is maintained independently, and then merged into a whole by a dedicated person, and the Linux Kernel has so far Open source collaboration using mailing lists and patch submissions. Some early open source projects used mailing lists and IRC for collaborative development:

• The origin of the mailing list (Mailing List) can be traced back to 1975. It is one of the earliest community forms on the Internet and an important tool on the Internet for information exchange and information publication among various groups.
  
• The Chinese of IRC (Internet Relay Chat) is generally called Internet Relay Chat. It is an Internet chat protocol pioneered in 1988 by Finn Jarkko Oikarinen. The working principle of IRC is very simple: A chats with B, the process is A ⇋ C ⇋ B, where C is the relay, usually the server.
  

  Most open source software using self-built Git hosting platforms will also build mirror warehouses on public online hosting platforms such as GitHub. For example, Yocto Project related code repositories, several main repositories of Linux Kernel, etc. Note that mirror warehouses are often for the convenience of viewing source code, and generally officials do not recommend collaboration such as feedback issues in mirror warehouses.

The Linux Kernel Organization

  The Linux Kernel Organization is a public benefit corporation that distributes the Linux Kernel and other open source software to the public. Founded in 2002 and headquartered in Los Angeles, California, it is recognized by the IRS as a 501©3 privately operating foundation.

  The Linux Kernel Organization is responsible for operating the kernel.org website and associated infrastructure. However, the Linux Kernel Organization seems to have few people. It is managed by The Linux Foundation, and funding, technical support, and human support are also provided by The Linux Foundation.

The Linux Foundation

  The Linux Foundation (The Linux Foundation) was established in 2000 by the Open Source Development Labs (Open Source Development Labs, OSDL) and the Free Standards Group (Free Standards Group, FSG). Dedicated to promoting, protecting and advancing the collaborative development of the Linux kernel and supporting "the largest shared technical resource in history".

  The Linux Foundation, which sponsors the work of Linux creator Linus Torvalds and lead maintainer Greg Kroah-Hartman, also extends its support program with events, training and certification, and open source projects. In addition, there are many independent projects under the Linux Foundation (such as Xen Project, Yocto Project).

Kernel source repository

  According to different development situations, Kernel divides the source code into a series of independent warehouses such as a mainline warehouse (Mainline), a stable version warehouse (Stable), an integration test warehouse (Linux-next) and many subsystem warehouses (Subsystem). storehouse. Each warehouse has a dedicated person for maintenance, independent development, and does not affect each other!

warehouse name	maintainer	Git warehouse address
Mainline	Linus Torvalds	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Stable	Stable Group	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Linux-next	Stephen Rothwell	git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Subsystem (such as net)	Netdev Group	https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git

  If you directly access Kernel's original code warehouse (which seems to be located in the Netherlands) in China, the speed is very slow. But the good news is that Code Aurora Forum provides a Linux Kernel mirror repository in Beijing: https://kernel.source.codeaurora.cn/. This mirror repository is exactly the same as git.kernel.org, and is managed by the same team, so its update speed is basically synchronized with git.kernel.org.

1. There are also some third-party Linux Kernel mirror warehouses in China, such as Tsinghua University Open Source Software Mirror Site . The update speed of these third-party mirror warehouses is often not very fast, and the content is not comprehensive enough
2. If you directly clone the Linux Kernel source code under Windows (there are many symbolic links, which are not supported by Windows), an error will be reported at the end of the clone, but it will not affect the reading of the code.
3. Do not push the code directly to the https://git.kernel.org warehouse, only the maintainers of the corresponding warehouse have permission

  All Kernel source code repositories are based on the mainline repository (Mainline). At first glance, the Linux Kernel code management looks a lot like the Monorepo mode, where everything is stored in the Mainline repository maintained by Linus Torvalds. Although the Linux Kernel provides a single file hierarchy as a shared namespace for all content, each repo remains independent from each other due to different application needs and focuses. In other words, the Linux kernel project is more like a Monotree composed of many repos than a Monorepo.

Mainline

  Mainline This repository is maintained by Linus Torvalds himself. It is where all new features are introduced into the final release of the Linux Kernel. The official address of the repository is: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . In addition, the warehouse has also made a mirror warehouse on Github: https://github.com/torvalds/linux.

1. The Mainline repository is equivalent to the main branch in our development.
2. Domestic source: http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/torvalds/linux.git
3. Almost no one develops directly based on the Mainline repository

  The Mainline repository has only one master branch, which is equivalent to the trunk of a tree and represents the development direction of the Linux Kernel. Only Linus Torvalds has permission to merge code in the Mainline repository. The Mainline repository is constantly evolving (new features are added periodically), and therefore, the Mainline repository does not require additional branches. For each version that meets the release requirements, Linus himself will release it by tagging, and the release cycle is usually 9 to 10 weeks.

  Mainline release version numbers are in a.bthe format . Generally, before an official version is released, a series of Release Candidate (RC) versions will be released first, and the Release Candidate version will be used from a.b-rc1the beginning until the release condition is met a.b. For example, before the release of the final version of v5.18, a total of eight RC versions, v5.18-rc1 to v5.18-rc8, were released.

Andrew Morton on the linux-kernel mailing list:
  No one knows when the kernel will be released because it is released based on perceived error states, not according to a preconceived timeline.

  Before Linux 1.0, the version number in the format of 0.xxyes . During the period from 1.0 to 2.6.11 a.b.c, the format a.b.c.dof . After 3.0, it returned to semantic version number version number a.b.cformat . In a.b.cthe format , x is the major version number, y is the minor version number, and z is the revision number. The upgrade of the major version number a usually includes major changes, the upgrade of the minor version number b includes both the introduction of new features and bugfixes, and the upgrade of the revision number c includes only bugfixes.

  The period between a certain official version and the next candidate version is called the merge window period, for example, the period between 5.17 and 5.18-rc1 is the merge window period of version 5.18. The merger window period is about 2 weeks or so. Adding new features is only allowed during the merge window period, and only defect revisions (Bugfix) are allowed in subsequent stages (RC versions).

  Since the Mainline warehouse is adding new features periodically, new features often mean more bugs. Although the Kernel in the Mainline warehouse will focus on problem fixes during the RC phase, it still cannot guarantee the stability of the Kernel in the Mainline warehouse. Not very good. Unless the developer really wants to experience some new features in advance, it is not recommended to use the Kernel in the Mainline repository.

Linux-stable

  The Linux-stable warehouse is used to track the released Linux Kernel version and fix various bugs. Its main maintainer is Greg Kroah-Hartman, the second largest figure in the Linux community. The official location of this repository is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/. Similarly, the warehouse has also established a mirror warehouse on Github: https://github.com/gregkh/linux.

1. The Linux-stable warehouse is equivalent to the Release branch in our development.
2. Domestic source: http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/stable/linux.git

  When Linus Torvalds releases a new version in the Mainline warehouse he maintains (that is, after a new Tag (such as 5.17) is created in the Mainline warehouse), he will immediately pull a copy from the master branch of the Mainline warehouse to Linux-stable master branch, and checkout a new branch (eg linux-5.17.y) based on the current latest master branch (eg 5.17). The branch name .yis indicated . where .yis a placeholder for a bugfix release.

  Subsequently, the newly created branch (for example, linux-5.17.y) will be handed over to the stable branch maintenance team led by Greg Kroah-Hartman for maintenance, to fix various problems, and when the release condition is finally met, by creating a new Tag on the branch way to publish. Because Linux-stable needs to fix various problems for each release version, you can't just use Tags, you must cooperate with the corresponding branch. Each branch is equivalent to the development trunk of the stable version, and the Tag on each branch is a stable version released to the outside world. Through the method of Branch + Tag, multiple different stable versions can be maintained and released.

  The format of the version number released by the stable version is further expanded. The format of the version number released by the Mainline is a.b.c, where a.bis the version number released by the Mainline a.b, cand increases from 1 at the time of release (for example, v5.17.1). Continue to repair and create new Tags (for example, v5.17.2), and the revisions will continue to increase until Linus Torvalds releases the next stable version in the Mainline repository maintained by Linus Torvalds, and Linux-stable will also open the next stable branch immediately after.

1. Kernel's version number does not have a revision a.b.0of
2. Publish as needed, normal release time is about two weeks, but can be longer if there are no pressing issues

  Not every stable version of Kernel released will be widely used, and the iteration speed of Kernel version is quite fast. After a stable release is released, it usually contains only a few revisions before the next stable release. Among them, some stable versions (such as version 5.15) will be marked as LTS (Long Term Support), and the Kernels of these versions will be maintained for a long period of time (the number of them will be very large) .a.b.c cThe following table gives some LTS stable release dates and end of support maintenance dates.

  There are corresponding rules for bug fixes in the Linux kernel: any bug fixes in the stable kernel are backported from the mainline tree, and the fixes merged into the corresponding branch of the Stable repository must have been submitted to the Mainline repository. This means that the mainline kernel will always have newer bug fixes released earlier in the stable tree. However, Stable repositories will not contain new features merged in Mainline repositories, so Stable repositories tend to be more stable.

About how a patch can be merged into the Stable branch, the official document: Everything you ever wanted to know about Linux -stable releases

  However, it is unknown whether the fixes submitted to the Mainline repository will work well on the old version that has been released (most of them are fine). Also, there are relatively few integration tests against released legacy versions. Therefore, there is no quantitative or qualitative metric that can be used to definitively say which version of the kernel is more stable!

The Kernel that most Linux users run is a custom version of the kernel provided by a Linux distribution

Subsystem

  Linux Kernel divides the source code into some relatively independent subsystems, and each subsystem is maintained by dedicated personnel. The warehouses of each subsystem can be found on https://git.kernel.org. The specific maintainers can be found in ./MAINTAINERSthe file . More convenient web version https://docs.kernel.org/process/maintainers.html.

It seems that some repositories on https://git.kernel.org are no longer maintained or replaced by new repositories for maintenance, but the original repositories are still preserved

  The subsystem repository usually contains a next branch, and some large subsystems even create a separate next repository for storing patches that need to be submitted to Linux-next. Additionally, subsystem maintainers can in turn pull patches from other maintainers. For example, a network tree is built from patches accumulated in specialized trees for network device drivers, wireless networks, and so on.

  The code contributed by most developers must first be reviewed by the subsystem administrator (Maintainer) (through the mailing list), and then can enter a specific subsystem warehouse, and then will be integrated in linux-next. Finally, those good patches are submitted to Linus Torvalds by the subsystem maintainers, and finally merged into the Kernel master branch.

Linux-next

  The Linux-next repository is used to store the patch codes that are expected to be merged into the Mainline during the next merge window, and is mainly maintained by Stephen Rothwell. The official original warehouse address is: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.

1. The Linux-next warehouse is equivalent to the Develop branch in our development.
2. Domestic source: http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/next/linux-next.git
3. https://www.kernel.org/doc/man-pages/linux-next.html

  Subsystems in the Linux Kernel undergo daily changes, some even across subsystems, and updates in the subsystem tree need to be integrated tested before they are merged into the mainline tree. The Linux-next repository is used to handle this integration testing. This repository pulls all subsystem trees into it almost daily, in this way linux-next gives a baseline of those patches that will go into the mainline kernel during the next merge.

  Linux-next is rebuilt daily from numerous subsystem trees, each of which is itself changing daily. So linux-next is a moving target, like mainline. However, unlike mainline, linux-next has no consistent or coherent history. Every day the linux-next tree is a fresh start, with a unique and short history.

  Linux-next contains the most cutting-edge Linux Kernel features, a new Tag is created almost every day in the warehouse, and the naming rules are next-年月日. The repository has become an integral part of the kernel development process, and all patches merged during a given merge window should actually make their way into the linux-next repository sometime before the merge window opens.

Join the Linux community

  The Linux Kernel still uses mailing lists and open source collaboration for patch submissions. To join the Linux community is to understand the cooperative development model, process and various specifications of the Linux Kernel, and strictly abide by the relevant regulations.

1. The Newbie Village of the Linux Community: https://kernelnewbies.org

  During years of development, the Linux community has formulated a series of strict specifications, such as source code coding specifications, code submission specifications, and so on. There is a special chapter in the official Linux Kernel document Working with the kernel development community to introduce in detail how to join the Linux community.

Mailing Lists

  The mailing list contains multiple email addresses. When a user sends an email to a real mailing list, all the email addresses contained in it can receive the email. Mailing list is a common and practical email application function. Its essence is to realize the function of mass mailing through a simple method: other people can receive the mail sent by someone to the mailing list.

  Subscribing to the mailing list is not required. Subscribing to a mailing list is equivalent to joining a group chat where we can view group chat messages (mails sent by anyone to our subscribed mailing list). You can directly use this mailbox to reply to the group chat message (reply to the specified email), but pay attention to the format requirements. If you don't subscribe, we won't be able to view other people's chat content (submit PATCH mail).

   Using the mailing list, the administrator can control the usage permissions of this mailing list, whether anyone can send letters to this mailing list, or only the members included in this list can send letters to it. In addition, when sending a letter to a mailing list, the recipient will not see who is on the mailing list.

The Linux mailing list is where anyone can post

VGER.KERNEL.ORG

  VGER.KERNEL.ORG is a Linux mailing list service site. The page lists the mail subscription addresses of all currently known Linux subsystems, and the background mail server VGER's Majordomo is responsible for processing our subscriptions.

1. Latest news from Kernel.org, their new mailing list service running under the new ‎‎lists.linux.dev‎‎ domain, following VGER.KERNEL.ORG will migrate to lists.linux.dev
2. Majordomo is no longer maintained, the current version is 1.94.5

  The first step to becoming a Linux developer is to find something you want to contribute at http://vger.kernel.org/vger-lists.html and subscribe to the corresponding mailing list. Subscribing or unsubscribing is as simple as sending an email with specific content to [email protected]. Subscribers have strict requirements on the content of subscribed emails:

1. Must be a plain text message
2. The length of the message content cannot exceed 100000 characters
3. The content of the email must be replied in a fixed format. Spaces, line breaks, etc. are not allowed. It seems that Majordomo has been improved and can handle some abnormal situations.

  Since the mailing list has a lot of content (the linux-kernel mailing list has 200~300 mails every day), it is recommended to use a separate mailbox for subscription. In addition, some netizens reported that some mailboxes in China may be blocked in the face of a large number of emails. I originally applied for a Google Gmail to subscribe to related mailing lists. The following is the whole process of subscribing to linux-embedded:

1. Send a subscription request. Just log in to your own web mailbox and send an email. Note: The default web page email is in HTML format, which needs to be changed to plain text format.
   
   1. If there is a mail client on the PC, just click subscribe on http://vger.kernel.org/vger-lists.html and the mail client will be opened automatically.
   2. Many mailboxes have their own signature function, choose not to use signature when subscribing
   3. Email headers are optional, VGER's Majordomo doesn't care about email headers. If you want to write, you can Subscribe 订阅的模块名, or even just write Hello.
   4. The email content can also directly include the mailbox: subscribe linux-kernel 你的邮箱. This method is not officially recommended.
   5. Do not copy the content directly from the web page, the copied content will usually be in rich text format with formatting
   6. Do not use clients such as Foxmail, he will change the encoding format of the mail, VGER's Majordomo does not support
2. Reply to confirm. If there is no problem with the subscription request email, we will receive a reply email from [email protected] asking us to confirm. The formatting requirements for replies are the same as for subscription requests.
   
   1. It may take a long time (on the order of hours, up to a day) to receive a reply email from [email protected], please be patient. Don't keep sending subscription requests, otherwise you will receive a lot of emails asking for confirmation later
   2. VGER's Majordomo will reply with two emails, the first one (titled Majordomo results:我们订阅的邮件标题) is that we have received our subscription request, and the second one (titled Confirmation for subscribe 订阅的模块名) contains the content that we need to confirm. And the interval between the two emails is quite long.
   3. Emails should be answered in the form of a rewrite, not a direct reply to the email
   4. According to the test, if HTML is used, VGER's Majordomo will also reply to confirm, but an error will be prompted in the email
3. Subscription succeeded. After confirming the successful reply, [email protected] will reply with two emails of successful subscription again. The first title is Welcome to 订阅的模块名, the second title is Majordomo results.
   
   1. It may take a long time (on the order of hours, up to a day) to hear back from [email protected]. And the interval between the two emails is quite long.
   2. Wait for a while and we will receive a large number of (some Linux modules have relatively few subscriptions) emails on the subscribed mailing list
4. If you want to unsubscribe, you only need to change subscribe in the email body to unsubscribe, and the other formats are exactly the same as the subscription request, just send it.

other mailing lists

  Besides the official VGER.KERNEL.ORG, there are some other Linux mailing lists, lists.infradead.org and listman.redhat.com are also commonly used mailing lists. These mailing lists usually have subscription lists that VGER.KERNEL.ORG does not have.

1. lists.infradead.org and listman.redhat.com support subscription on the web
2. I have not subscribed on it, refer to the subscription process of a netizen: https://blog.csdn.net/flyingnosky/article/details/100071996

mail archive

  The Linux Kernel officially provides lore.kernel.org for archiving all Linux collaborative development emails. But the archives on lore.kernel.org are not complete, and each independent module may also provide archives for subscription mailings elsewhere (see http://vger.kernel.org/vger-lists.html for instructions).

  The Linux community takes mail archives very seriously, which is a big reason for the new mail subscription service lists.linux.dev. Through the mail archive service, we can see almost all the mail content of Linux collaborative development, and we can also find the corresponding PATCH in it.

document

  Kernel's documentation (source directory/Documentation/*) uses the documentation system built by Sphinx. Sphinx is Python-based and uses the reStructuredText language format, usually with a file extension of .rst. The Sphinx documentation system uses the make command to generate published documentation, which can generate html, pdf and other formats.

  The online hosting address of Kernel documentation is: https://docs.kernel.org/. The online version of the document is the document in html format generated by Sphinx 源码目录/Documentation/*based , and there is no difference in content between the two.

Submit PATCH

  If you want to contribute your own code to the Linux Kernel, you must strictly abide by the relevant norms of the Linux community. These specifications are introduced in detail in a special chapter in the official Linux Kernel document Working with the kernel development community . Including but not limited to coding standards, mailing list usage, PATCH format, email format, etc.

  Do not push code directly to the clone warehouse, only the maintainers of the corresponding warehouse have permission. As I said more than once before, the Linux Kernel is still using the open source collaboration method of mailing lists and patch submissions. The basic process is shown in the figure below:

Environment and Tools

  If a worker wants to do a good job, he must first sharpen his tools. Linux development requires a Linux environment, and you can choose any Linux distribution you like (I use Ubuntu 22.04 LTS here). Some other tools, such as git, git-email, make, gcc, etc., can be installed with corresponding commands according to your own environment.

1. Linux Kernel uses Git to manage code, requiring us to use Git proficiently, because many operations use Git commands.
2. Do not use mail client to send PATCH, https://docs.kernel.org/process/email-clients.html lists some clients how to use it correctly

  In order to ensure that the sent PATCH format is correct, generally use the commands provided by Git itself git send-emailto send PATCH. After Git is installed by default (please configure the Git user name and mailbox first), there is no send-email, which needs to be installed separately (Ubuntu: sudo apt install git-email). Then it is to configure git-email. I'm using Gmail here. Direct command: nano ~/.gitconfig.

  In addition, you must also ensure that the SMTP function and related permissions are enabled in your mailbox, otherwise you will not be able to use to git send-emailsend emails. Many mailboxes are not opened by default. For example, the Gmail I use here needs to be modified to use the following settings (due to well-known reasons, special tools are required to access Gmail): There is a problem here, the mailbox that sends PATCH (

  configured git send-emailmailbox ), the mailbox configured by Git (Git uses username and mailbox to identify the submitter of the code), and the mailbox used to subscribe to the mailing list must be the same? the answer is negative. You can choose to use the same mailbox, or it doesn't matter. The mailing list has already been said before, generally you must use a single mailbox, otherwise you will face a large number of mails to find the content related to yourself. It is best to use one mailbox for Git configuration and one for sending PATCH.

  By default, the information specified by the From: line in the BODY of the email will be logged in the permanent changelog as the author of the patch. If the From: line is missing, the From: line in the email HEADER will be used to identify the patch author in the changelog. The mailbox of the maintainer when replying is the mailbox that sent the PATCH, and they don't care about the mailbox configured by Git.

Select Kernel source code

  The next step is to correctly select and obtain the Kernel source code tree. Directly cloning Linus Torvalds' Mainline repository is an option, however, more often than not, development is for specific subsystems. Most subsystem maintainers have their own code warehouses. Usually, check the MAINTAINERS file in the Kernel source code directory (or online documentation https://docs.kernel.org/process/maintainers.html) to find the corresponding warehouse address .

Do not push code directly to the clone warehouse, only the maintenance personnel of the corresponding warehouse have permission

  Some developers suggest linux-next as the main branch for future development, the linux-next branch is indeed well beyond the trunk and more representative of new improvements that will be merged into the trunk. However, the volatility of linux-next often makes it a difficult development target. As Stephen Rothwell, maintainer of the linux-next tree, puts it: "One of the downsides of the way linux-next works is that because it's recreated every day, you can't really base anything you want to merge into it on. "

modify the code

  The next step is to modify the code and submit the changes. Try to ensure that the modifications in each Commit are logically independent. A Commit containing multiple types of modifications will cause PATCH to be unable to be independent. You can view the format submitted by others by viewing the history of the file modified by the file:

  The format of the Commit information is strictly limited. For details, refer to Documentation/process/submitting-patches.rstthe file or directly view the online document https://docs.kernel.org/process/ submitting-patches.html. PATCHs that do not conform to the Commit format may be ignored directly. The following is a basic description of a Commit template:

drivers: fix some error

Why I do these changes and how I do it.

Signed-off-by: My Name <my_email@gmail.com>

Each line should not exceed 75 characters. If the content is too long, please wrap it consciously:

• Line 1: Use short text to explain what this Commit did. The format is 子系统名: 修改说明(note that there is a space after the colon).
• Second line: empty line
• Line 3: Explain in detail why and how to make this modification. There can be as many lines as you like, and each line should not exceed 75 characters.
• Line 4: blank line
• Line 5: label line, used to declare some information for the patch, the format is tag: info(note that there is a space after the colon). For multiple labels, each label occupies a separate line. Commonly used tags are:
  • Signed-off-by : Indicates that the patch submitter has the right to submit the patch for inclusion in the kernel. It means that the author has signed the kernel developer's original certification agreement, which can be found in the kernel document SubmittingPatches. This label is required, and patches without this agreement will not be accepted by the mainline.
  • Acked-by : Indicates an agreement by another developer (usually the maintainer of the associated code) that the patch is suitable for inclusion in the kernel.
  • Tested-by : It states that the patch has been tested by an engineer, and no problems were found, and it can work normally.
  • Reviewed-by : The specified developer has checked the correctness of the patch, see the reviewer statement in the document SubmittingPatches.
  • Reported-by : Indicates who proposed the problem fixed by the patch.
  • Cc : The designated person received a copy of the patch and was given an opportunity to comment on it.

Generate PATCH

  It is guaranteed that each patch only addresses one issue. If the modification contains a lot of Commits, it needs to be split into multiple different PATCHs according to the situation. Note that each PATCH must pass its own strict test, and the most basic point is to ensure that there are no errors in compilation. If the PATCH has been tested by others, be sure to add the Tested-by tag when submitting.

  Generating PATCH is relatively simple, mainly because of the use of git format-patchcommands . This needs to be used according to your own development situation and with the various parameters git format-patchof . The following is an example:

  where --subject-prefix='PATCH'is to add a prefix to the email title. Since maintainers receive a lot of emails, they usually add a prefix to the subject line so that maintainers can distinguish emails well. Possible values ​​are:

prefix	meaning
PATCH	Regular patching (default). If several versions have been modified, you can also add a version number, for examplePATCH v2
RFC	It is not to be officially mentioned, I hope to discuss this patch together
RESEND	Resending due to no response received

  Next, you need to run the command ./scripts/checkpatch.pl 你的 PATCHto check if there is any problem with your PATCH format. It must be 0 errors, 0 warnings.

send PATCH

  After ensuring that there are no problems with the PATCH, you can send the PATCH to the upstream maintainer. First of all, by running the command ./scripts/get_maintainer.pl -f 你的 patchor ./scripts/get_maintainer.pl -f 你的修改的文件to automatically list the corresponding maintainers and the corresponding mailing list.

  Next, use directly git send-email --to 收件人邮箱1,收件人邮箱2 --cc 抄送1,抄送2 your.patchto send PATCH. Include only one PATCH per email, CC at least one relevant mailing list, and do not send emails to unrelated lists. In general, the mailing list adopts carbon copy ( --cc), other personnel choose to send directly ( --to), and multiple mailboxes are separated by commas. git send-emailEmails of people given From: , Signed-off-by: in the patch are automatically copied.

  Then wait for the corresponding feedback in the email! After receiving the feedback, please give an explanation patiently, and if there are indeed problems, revise them in time. In the end there is no problem, just wait for your PATCH to be merged.

reference

1. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
2. https://tinylab.org/linux-repo-intro/
3. https://blog.csdn.net/jasonactions/article/details/120776434
4. https://opensourceway.community/posts/contribute_to_community/how_to_participate_in_the_linux_community/
5. https://lwn.net/Articles/289013/
6. https://blog.csdn.net/jcf147/article/details/123719000
7. https://zhuanlan.zhihu.com/p/138315470
8. https://cloud.tencent.com/developer/article/1525774
9. https://blog.51cto.com/mirage1993/1912785