Brief introduction
This article shows step by step how to generate a simple Linux kernel patch and submit it it to the Linux community. To show the steps for submitting patches to the community. English name of this article: "Submit Patches Step by Step"
Author brief introduction
Xie Baoyou, who has worked on the programming front line for 20 years, has worked on the Linux operating system for nearly 10 years. Currently, he is the Maintainer of the Linux ZTE platform, submitting 130 patches and more than 4,000 lines of code to the community. At the same time, he is also the translator of Deep Understanding of Parallel Programming. Paul E.McKeney is the leader of the IBM Linux Center and Linux RCU Maintainer.
Author's contact information: baoyou.xie@gmail.com
Wechat or QQ: 373364645
Welcome to pay attention to account number:
I. Due Psychology
In Section 11.1.2 of Deep Understanding Parallel Programming, Paul says that verification and testing require a good mentality. The code should be validated with a destructive, even a little hatred, and sometimes it should be taken into account that many people's lives depend on the probability of the correctness of our code. In short, mentality has an important impact on the success or failure of things.
Similarly, we should have the right mindset before submitting patches to the community:
- Our code may affect many people's lives, so we must be careful.
- Pessimistically, if the patch is not done well, it will be drowned by the community bulls. Of course, it's more likely that Daniel is too lazy to spit at you:) So please be responsible for your reputation before submitting the patch.
- Optimistically, community bulls are generally Nice, if your level is really cattle.
- To be more optimistic, the high quality patches you submit may bring you good reputation and satisfactory work.
- It should be emphasized that in the community, do not confront Maintainer. Be courteous to Maintainer as you are to school teachers. Believe it or not, I believe it anyway.
If you are as confident as I am, read on.^-^
II. Preparations
Before starting work, please prepare the following work:
1. Install a Linux.
Whether it's ubuntu, centos or other Linux distributions, it's OK. I personally use Ubuntu version 16.04. Although I've tried to install git under windows, eventually you'll find that using git to submit patches under windows can almost be described as pain.
2. Install git.
The default Linux distribution generally has git installed. If not, just find a git book. This is not detailed here. The better git data are:
http://git.oschina.net/progit/
https://item.jd.com/11615420....
3. configure git
A. Configuring usernames and mailboxes
When configuring user names, please note that community friends are used to communicating in English, that is, first name, last name. This can affect community email discussions, so it needs to be noted.
When configuring mailboxes, you should also pay attention to them. The community will block some of the country's famous mail servers. So I suggest you apply for a gmail mailbox.
The following is my configuration:
xiebaoyou@ThinkPad-T440$git config -l | grep "user" user.email=baoyou.xie@linaro.org user.name=Baoyou Xie
B. Configuring sendemail
You can manually modify the ~/.git config, or add the [sendemail] section to the. git/config file under the GIT repository. This configuration is used to specify mail server parameters used to send patches.
The following is my configuration for reference:
\[sendemail\] smtp encryption= tls smtp server= smtp.gmail.com smtp user= baoyou.xie@linaro.org smtp serverport= 587
The configuration of gmail mailbox is rather troublesome. It needs to follow the instructions of google to make certificates. When the configuration is complete, send yourself a test patch with the following command:
git send-email your.patch --to your.mail --cc your.mail
C. Download source code
First, use the following command to pull the Linux main branch code maintained by linus to the local location:
git clone ssh://git@dev-private.git.linaro.org/zte/kernel.git
This process is rather long, please wait patiently.
Usually, the main branch code of Linux is not new enough. If you make patches based on this code, you probably won't be able to merge into Maintainer smoothly. In other words, Maintainer will send patches back to you and ask you to make them again. So, in general, you need to add other branches, especially linux-next branches, with the following commands. Emphasize that you need to get used to working on linux-next branches.
git remote add linux-nexthttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git remote add staging https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git git remote add net git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Then use the following command to pull the code from the three branches to the local area:
git fetch --tags linux-next git fetch --tags staging git fetch --tags net
Some Maintainers maintain their own branch of code, so you can find the Maintainer of the corresponding file and its git address in the kernel source directory MAINTAINERS file.
For example, the information of the watchdog module is as follows:
WATCHDOGDEVICE DRIVERS M: Wim Van Sebroeck <wim@iguana.be> R: Guenter Roeck <linux@roeck-us.net> L: linux-watchdog@vger.kernel.org W: http://www.linux-watchdog.org/ T: gitgit://www.linux-watchdog.org/linux-watchdog.git S: Maintained F: Documentation/devicetree/bindings/watchdog/ F: Documentation/watchdog/ F: drivers/watchdog/ F: include/linux/watchdog.h F: include/uapi/linux/watchdog.h
Among them, git://www.linux-watchdog.org/linux-watchdog.git is its git address.
You can pull the watchdog code locally with the following command:
gitremote add watchdog git://www.linux-watchdog.org/linux-watchdog.git gitfetch --tags watchdog
Of course, here's a reminder that the information in MAINTAINERS may not be accurate. At this time, you may need to use google, or ask friends in the community, or directly ask the author himself. However, in general, branch work based on linux-next will not be too problematic. There are real problems to disturb the author himself.
4. It's important to read Documentation/Submitting Patches.
5. Detecting source code
git branch mybranch next-20170807
This command indicates that the tag 20170807 of the linux-next branch is used as the basis for the local mybranch.
git checkout mybranch
3. Looking for soft persimmons
If there are no adventures, chefs usually start from small jobs. It's impossible to maintain an important module or fix some very important faults from the beginning. So how should we start participating in the community? Of course, it's about finding soft persimmons. With patches made with soft persimmons, Maintainer can't refuse to join your patches. Of course, the main reason for doing this is to mix up with Maintainer. Otherwise, people may not pay attention to you when you issue important patches in the future.
What kind of persimmon is the softest? Here are the answers:
- Eliminate compilation warnings
- Coding formats, such as misspelling of words in comments, irregular alignment, and code formats that do not meet community requirements.
The suggestion is to start with "eliminating compilation warnings". Many Daniels in the community grew up in this way.
We usually compile the kernel, and basically do not encounter compilation warnings. Is the kernel perfect without compiling warnings? Let's try the following steps:
First, configure the kernel and select all modules:
makeARCH=arm64 allmodconfig
Note that "allmodconfig" is a useful configuration, which we can understand temporarily as compiling all modules. This allows us to find compilation warnings in all modules.
The following command starts compiling all modules:
make ARCH=arm64 EXTRA_CFLAGS="-Wmissing-declarations -Wmissing-prototypes" CROSS_COMPILE=/toolchains/aarch64-linux-gnu/bin/aarch64-linux-gnu-
The EXTRA_CFLAGS="-Wmissing-declarations-Wmissing-prototypes" parameter represents a warning that tracks all missing-declarations, missing-prototypes types types.
CROSS_COMPILE=/toolchains/aarch64-linux-gnu/bin/aarch64-linux-gnu-is the specified cross-compiler link path, which needs to be modified according to your actual situation. Of course, if it's an x86 architecture, you don't need to specify this parameter.
During the compilation process, we found the following errors:
scripts/Makefile.build:311:recipe for target 'drivers/staging/fsl-mc/bus/dpio/qbman-portal.o' failed
We can simply ignore the driver/staging/fsl-mc/bus/dpio/qbman-portal.c file. In drivers/staging/fsl-mc/bus/dpio/Makefile file file, it is found that the compilation of this file depends on macro CONFIG_FSL_MC_DPIO.
So we modify the compilation command to continue compiling with the following commands:
make CONFIG_ACPI_SPCR_TABLE=n ARCH=arm64 EXTRA_CFLAGS="-Wmissing-declarations -Wmissing-prototypes" CROSS_COMPILE=/toolchains/aarch64-linux-gnu/bin/aarch64-linux-gnu-
Note the command "CONFIG_ACPI_SPCR_TABLE=n", which forces the CONFIG_ACPI_SPCR_TABLE configuration to be closed.
When compiled, did we find a lot of warnings? Especially in the drivers directory.
Below are the warnings I found in next-20170807:
/dimsum/git/kernel.next/drivers/clk/samsung/clk-s3c2410.c:363:13:warning: no previous prototype for 's3c2410\_common\_clk\_init'\[-Wmissing-prototypes\] void\_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, ^ CC drivers/clk/samsung/clk-s3c2412.o /dimsum/git/kernel.next/drivers/clk/samsung/clk-s3c2412.c:254:13:warning: no previous prototype for 's3c2412\_common\_clk\_init'\[-Wmissing-prototypes\] void\_\_init s3c2412\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, ^ CC drivers/clk/samsung/clk-s3c2443.o /dimsum/git/kernel.next/drivers/clk/samsung/clk-s3c2443.c:388:13:warning: no previous prototype for 's3c2443\_common\_clk\_init' \[-Wmissing-prototypes\] void\_\_init s3c2443\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f,
In the next section, we will make patches based on these warnings.
IV. Making Patches
It's easy to eliminate these warnings. Declare these functions as static. Here are my changes:
git diff diff --git a/drivers/clk/samsung/clk-s3c2410.c b/drivers/clk/samsung/clk-s3c2410.c index e0650c3..8f4fc5a 100644 \--- a/drivers/clk/samsung/clk-s3c2410.c +++ b/drivers/clk/samsung/clk-s3c2410.c @@ -360,7 +360,7 @@ static void \_\_inits3c2410\_common\_clk\_register\_fixed\_ext( samsung\_clk\_register\_alias(ctx, &xti\_alias, 1); } \-void \_\_init s3c2410\_common\_clk\_init(structdevice\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, intcurrent\_soc, void\_\_iomem \*base) { diff --git a/drivers/clk/samsung/clk-s3c2412.c b/drivers/clk/samsung/clk-s3c2412.c index b8340a4..2a2ce06 100644 \--- a/drivers/clk/samsung/clk-s3c2412.c +++ b/drivers/clk/samsung/clk-s3c2412.c @@ -251,7 +251,7 @@ static void \_\_init s3c2412\_common\_clk\_register\_fixed\_ext( samsung\_clk\_register\_alias(ctx, &xti\_alias, 1); } \-void \_\_init s3c2412\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2412\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, unsigned long ext\_f, void \_\_iomem \*base) { struct samsung\_clk\_provider \*ctx; diff --gita/drivers/clk/samsung/clk-s3c2443.c b/drivers/clk/samsung/clk-s3c2443.c index abb935c..f0b88bf 100644 \--- a/drivers/clk/samsung/clk-s3c2443.c +++ b/drivers/clk/samsung/clk-s3c2443.c @@ -385,7 +385,7 @@ static void \_\_inits3c2443\_common\_clk\_register\_fixed\_ext( ARRAY\_SIZE(s3c2443\_common\_frate\_clks)); } \-void \_\_init s3c2443\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2443\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, int current\_soc, void \_\_iomem \*base)
Once again, the warning was eliminated. It turns out that community work is so simple:
But please allow me to pour a basin of cold water!
First you try to make a patch with the following commands.
git add drivers/clk/samsung/clk-s3c2410.c git add drivers/clk/samsung/clk-s3c2412.c git add drivers/clk/samsung/clk-s3c2443.c git commit drivers/clk/samsung/ \[zxic/67184930591\] this is my test 3 files changed, 3 insertions(+), 3deletions(-) gitformat-patch -s -v 1 -1
The patches generated are as follows:
cat v1-0001-this-is-my-test.patch From 493059190e9ca691cf08063ebaf945627a5568c7 Mon Sep 17 00:00:00 2001 From: Baoyou Xie<baoyou.xie@linaro.org> Date: Thu, 17 Aug 2017 19:23:13 +0800 Subject: \[PATCH v1\] this is my test Signed-off-by: Baoyou Xie<baoyou.xie@linaro.org> \--- drivers/clk/samsung/clk-s3c2410.c | 2 +- drivers/clk/samsung/clk-s3c2412.c | 2 +- drivers/clk/samsung/clk-s3c2443.c | 2 +- 3files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/clk/samsung/clk-s3c2410.c b/drivers/clk/samsung/clk-s3c2410.c index e0650c3..8f4fc5a 100644 \--- a/drivers/clk/samsung/clk-s3c2410.c +++ b/drivers/clk/samsung/clk-s3c2410.c @@ -360,7 +360,7 @@ static void \_\_init s3c2410\_common\_clk\_register\_fixed\_ext( samsung\_clk\_register\_alias(ctx,&xti\_alias, 1); } \-void \_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, int current\_soc, void \_\_iomem \*base) { diff --git a/drivers/clk/samsung/clk-s3c2412.c b/drivers/clk/samsung/clk-s3c2412.c index b8340a4..2a2ce06 100644 \--- a/drivers/clk/samsung/clk-s3c2412.c +++ b/drivers/clk/samsung/clk-s3c2412.c @@ -251,7 +251,7 @@ static void \_\_inits3c2412\_common\_clk\_register\_fixed\_ext( samsung\_clk\_register\_alias(ctx,&xti\_alias, 1); } \-void \_\_init s3c2412\_common\_clk\_init(structdevice\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2412\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, unsigned long ext\_f, void \_\_iomem \*base) { struct samsung\_clk\_provider \*ctx; diff --git a/drivers/clk/samsung/clk-s3c2443.c b/drivers/clk/samsung/clk-s3c2443.c index abb935c..f0b88bf 100644 \--- a/drivers/clk/samsung/clk-s3c2443.c +++ b/drivers/clk/samsung/clk-s3c2443.c @@ -385,7 +385,7 @@ static void \_\_inits3c2443\_common\_clk\_register\_fixed\_ext( ARRAY\_SIZE(s3c2443\_common\_frate\_clks)); } \-void \_\_init s3c2443\_common\_clk\_init(structdevice\_node \*np, unsigned long xti\_f, +static void \_\_init s3c2443\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, int current\_soc, void \_\_iomem \*base) { \-- 2.7.4
You can try git send-email v1-0001-this-is-my-test.patch --to baoyou.xie@linaro.org to send the patch to Maintainer. Remember to prepare a basin and take your saliva:)
Before making the correct patch, we need where the wrong patch is:
1. It should be split into three patches.
Maybe this is worth considering, because all three files are driven by the same driver: clk: samsung. Maybe Maintainer thinks it's the same driver, so it's possible to make a patch.
I think it should be divided into three parts.
Of course, Maintainer's opinion should prevail. Different Maintainers may have different opinions.
2. Patch description is too LOW.
3. The patch format is incorrect.
4. The patch is incorrect.
In the next section, we will solve these problems one by one.
But first we should return the patch. Use the following commands:
git reset HEAD~1
5. Make the right patches
1. Patch Description
The first line of the patch is the title, which is more important. It should first be the module name.
But how do we find out which module the drivers/clk/samsung/clk-s3c2412.c file belongs to?
Try the following command to see the history patch for drivers/clk/samsung/clk-s3c2412.c file:
root@ThinkPad-T440:/dimsum/git/kernel.next# git log drivers/clk/samsung/clk-s3c2412.c commit 02c952c8f95fd0adf1835704db95215f57cfc8e6 Author:Martin Kaiser <martin@kaiser.cx> Date: Wed Jan 25 22:42:25 2017 +0100 clk: samsung:mark s3c....\_clk\_sleep\_init() as \_\_init
ok, the module name is "clk:samsung"
Below is the description I added for this patch, the first line of which is the title:
clk: samsung: mark symbols static where possible for s3c2410 We get 1 warnings when building kernel withW=1: /dimsum/git/kernel.next/drivers/clk/samsung/clk-s3c2410.c:363:13:warning: no previous prototype for 's3c2410\_common\_clk\_init'\[-Wmissing-prototypes\] void \_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, In fact, this function is only used in thefile in which they are declared and don't need a declaration, butcan be made static. So this patch marks these functions with 'static'.
I copied this description from other patches. There are several points to note:
- "for s3c2410" was deliberately added to the title to distinguish it from the other two patches.
- In the word "1 warnings", the plural is used incorrectly because of duplication.
- The path name'/ dimsum/git/kernel.next /'is related to my local path and should not appear in the patch.
- The warning description is more than 80 characters, but this is a special case. More than 80 characters are allowed here.
Maintainer will not be happy if these problems are not dealt with! If Maintainer complains and you don't fix it, the patch will be ignored.
The revised patch is described as follows:
clk: samsung: mark symbols static wherepossible for s3c2410 We get 1 warning when building kernel withW=1: drivers/clk/samsung/clk-s3c2410.c:363:13:warning: no previous prototype for 's3c2410\_common\_clk\_init'\[-Wmissing-prototypes\] void\_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, In fact, this function is only used in thefile in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'.
Our patch description must pay attention to the use of words and avoid the mistake of writing "unused" as "no used".
Repeatedly using git add, git commit submits patches to the GIT repository.
I want to celebrate my success. Use the git command to see the three patches we just submitted:
root@ThinkPad-T440:/dimsum/git/kernel.next#git log drivers/clk/samsung/ commit0539c5bc17247010d17394b0dc9f788959381c8f Author: Baoyou Xie<baoyou.xie@linaro.org> Date: Thu Aug 17 20:43:09 2017 +0800 clk: samsung: mark symbols static where possible for s3c2443 We get 1 warning when building kernel with W=1: drivers/clk/samsung/clk-s3c2443.c:388:13: warning: no previous prototypefor 's3c2443\_common\_clk\_init' \[-Wmissing-prototypes\] void \_\_init s3c2443\_common\_clk\_init(struct device\_node \*np, unsignedlong xti\_f, In fact, this function is only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. commitc231d40296b4ee4667e3559e34b00f738cae1e58 Author: Baoyou Xie<baoyou.xie@linaro.org> Date: Thu Aug 17 20:41:38 2017 +0800 clk: samsung: mark symbols static where possible for s3c2412 We get 1 warning when building kernel with W=1: drivers/clk/samsung/clk-s3c2412.c:254:13: warning: no previous prototypefor 's3c2412\_common\_clk\_init' \[-Wmissing-prototypes\] void \_\_init s3c2412\_common\_clk\_init(struct device\_node \*np, unsignedlong xti\_f, In fact, this function is only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. commit ff8ea5ed4947d9a643a216d51f14f6cb87abcb97 Author: Baoyou Xie<baoyou.xie@linaro.org> Date: Thu Aug 17 20:40:50 2017 +0800 clk: samsung: mark symbols static where possible for s3c2410
But do you find anything incorrect in the patch description?
Maintainer may not find this problem, however, and then the patch may be received into the kernel.
Next we generate patches:
root@ThinkPad-T440:/dimsum/git/kernel.next#git format-patch -s -3 0001-clk-samsung-mark-symbols-static-where-possible-for-s.patch 0002-clk-samsung-mark-symbols-static-where-possible-for-s.patch 0003-clk-samsung-mark-symbols-static-where-possible-for-s.patch
In fact, our patch is still wrong.
Before sending patches, we need to check patches with scripts:
root@ThinkPad-T440:/dimsum/git/kernel.next#./scripts/checkpatch.pl 000\* \--------------------------------------------------------------- 0001-clk-samsung-mark-symbols-static-where-possible-for-s.patch \--------------------------------------------------------------- WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: void\_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, WARNING: line over 80 characters #29: FILE:drivers/clk/samsung/clk-s3c2410.c:363: +static void \_\_init s3c2410\_common\_clk\_init(struct device\_node \*np, unsigned long xti\_f, total: 0 errors, 2 warnings, 8 lineschecked
Note the output of warnings, the first of which is that there are too long statements in our description. As mentioned earlier, this warning can be ignored.
But the second warning tells us that there are more than 80 lines of code. This is a warning that cannot be ignored and must be dealt with.
Use the "git resetHEAD~3" command to roll back three patches. Re-modify the code:
static void __init s3c2410_common_clk_init(struct device_node *np, unsigned long xti_f,
Modified to
static void __init s3c2410_common_clk_init(struct device_node *np, unsigned long xti_f,
It can also be modified to
static void __init s3c2410_common_clk_init(struct device_node *np, unsigned long xti_f,
I personally use the first method, because looking at other code is also the first way to modify.
Resubmit the patch and generate the patch with the gitformat-patch command.
6. Send patches
Once the correct patch is generated, check patch. PL again to check the patch correctness.
After making sure it's all right, you're ready to send it to Maintainer.
But who should the patch be sent to? This can be viewed with get_maintainer.pl:
root@ThinkPad-T440:/dimsum/git/kernel.next#./scripts/get_maintainer.pl 000* Kukjin Kim <kgene@kernel.org>(maintainer:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES) Krzysztof Kozlowski <krzk@kernel.org>(maintainer:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES) Sylwester Nawrocki<s.nawrocki@samsung.com> (supporter:SAMSUNG SOC CLOCK DRIVERS) Tomasz Figa <tomasz.figa@gmail.com>(supporter:SAMSUNG SOC CLOCK DRIVERS) Chanwoo Choi <cw00.choi@samsung.com>(supporter:SAMSUNG SOC CLOCK DRIVERS) Michael Turquette<mturquette@baylibre.com> (maintainer:COMMON CLK FRAMEWORK) Stephen Boyd <sboyd@codeaurora.org>(maintainer:COMMON CLK FRAMEWORK) linux-arm-kernel@lists.infradead.org(moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES) linux-samsung-soc@vger.kernel.org (moderatedlist:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES) linux-clk@vger.kernel.org (open list:COMMONCLK FRAMEWORK) linux-kernel@vger.kernel.org (open list)
Next, you can send patches with the git send-email command:
git send-email 000* --tokgene@kernel.org,krzk@kernel.org,s.nawrocki@samsung.com,tomasz.figa@gmail.com,cw00.choi@samsung.com,mturquette@baylibre.com,sboyd@codeaurora.org--cc linux-arm-kernel@lists.infradead.org,linux-samsung-soc@vger.kernel.org,linux-clk@vger.kernel.org,linux-kernel@vger.kernel.org
Note who should be the recipient of mail and who should be the copier. In this case, patches are experimental and can be sent to mailing list accounts without being copied.
Reminder: You should send the patch to yourself first, check it out before sending it out. If you have a friend who has a high prestige in the community, you can also copy it to him. If necessary, maybe he can give you some help. This helps to integrate patches smoothly into the community.
Important Reminder: This article is mainly about experimental patches to open community doors. Really important patches may need to be revised over and over again before they can be incorporated into the community. I know there are patches that haven't been able to fit into the community for more than two years, because there are always areas that need improvement, and maybe some community politics:)
More exciting updates... Welcome to pay attention to account number: