Your patches should be generated based on the latest openEuler branch using git-format-patch. If your patches are in a patchset, it is better to use the –cover-letter option to describe what the patchset does.
Use scripts/checkpatch.pl to ensure that no coding style issue exists.
In addition, ensure that your patches comply with the unified openEuler patch format described below.
Step 3 Send your patches to the openEuler mailing list.
The sign-off is a simple line at the end of the explanation of the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open source patch. The rules are pretty simple. You can certify as below:
Developer’s Certificate of Origin 1.1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file;
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file;
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Additional changelog should include at least one of the following:
1. Why we should apply this patch
2. What real problems in the product does this patch resolved
3. How could we reproduce this bug or how to test
4. Other useful information for help to understand this patch or problem
The detailed information is very useful for migrating a patch to another kernel branch.
Example for mainline patch:
```cpp
mainline inclusion [M]
from $mainline-version [M]
commit $id [M]
category: $category [M]
bugzilla: $bug-id [O]
CVE: $cve-id [O]
additional changelog [O]
--------------------------------
original changelog
Signed-off-by: $yourname <$yourname@huawei.com> [M]
($mainline-version could be mainline-3.5, mainline-3.6, etc...)
Examples
mainline inclusion
from mainline-4.10
commit 0becc0ae5b42828785b589f686725ff5bc3b9b25
category: bugfix
bugzilla: 3004
CVE: N/A
The patch fixes a BUG_ON in the product: Injecting a single bit ECC error to the memory before system boot using hardware inject tools will cause a large amount of CMCI during system booting .
[ 1.146580] mce: [Hardware Error]: Machine check events logged
[ 1.152908] ------------[ cut here ]------------
[ 1.157751] kernel BUG at kernel/timer.c:951!
[ 1.162321] invalid opcode: 0000 [#1] SMP
-------------------------------------------------
original changelog
<original S-O-B>
Signed-off-by: Zhang San <zhangsan@huawei.com>
Tested-by: Li Si <lisi@huawei.com>
Email client - Thunderbird settings
If you are a new developer in the kernel community, it is highly recommended that you use the Thunderbird mail client.
Thunderbird Installation
Obtain the English version of Thunderbird from [http://www.mozilla.org/](/p24137568/kernel/tree/openEuler-1.0-LTS/ http:/www.mozilla.org) and install it on your system.
1 Use the plain text format instead of the HTML format.
Choose Options > Account Settings > Composition & Addressing, and do NOT select Compose message in HTML format.
2 Editor settings
Tools > Options> Advanced > Config editor
- To bring up the Thunderbird’s registry editor, set mailnews.send_plaintext_flowed to false.
- Disable HTML Format: Set mail.identity.id1.compose_html to false.
- Enable UTF-8: Set prefs.converted-to-utf8 to true.
- View messages in UTF-8: Set mailnews.view_default_charset to UTF-8.
- Set mailnews.wraplength to 9999 to avoid auto-wrap.
Linux kernel
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use make htmldocs or
make pdfdocs. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.
关于
The openEuler kernel is the core of the openEuler OS, serving as the foundation of system performance and stability and a bridge between processors, devices, and services.
How to Contribute
[How to Contribute](#How to Contribute)
- [Sign the CLA](#Sign the CLA)
- [Steps of submitting patches](#Steps of submitting patches)
- [Use the unified patch format](#Use the unified patch format)
- [Define the patch format](#Define the patch format)
- Examples
- [Email client - Thunderbird settings](#Email client - Thunderbird settings)
[Linux kernel](#Linux kernel)
Sign the CLA
Before making any contributions to openEuler, sign the CLA first.
Address: https://openeuler.org/en/cla.html
Steps of submitting patches
Step 1 Compile and test your patches.
Step 2 Generate patches.
Your patches should be generated based on the latest openEuler branch using git-format-patch. If your patches are in a patchset, it is better to use the –cover-letter option to describe what the patchset does.
Use scripts/checkpatch.pl to ensure that no coding style issue exists.
In addition, ensure that your patches comply with the unified openEuler patch format described below.
Step 3 Send your patches to the openEuler mailing list.
To do so, run the following command:
git send-email *.patch -to="kernel@openeuler.org" --suppress-cc=all
NOTE: Add –suppress-cc=all if you use git-send-email; otherwise, the email will be copied to all people in the upstream community and mailing lists.
For details about how to send patches using git-send-email, see https://git-scm.com/docs/git-send-email.
Step 4 Mark “v1, v2, v3 …” in your patch subject if you have multiple versions to send out.
Use the –subject-prefix=”PATCH v2” option to add the v2 tag to the patchset.
git format-patch --subject-prefix="PATCH v2" -1
Subject examples:
Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings
Subject: [PATCH v3] ext2: improve scalability of bitmap searching
Step 5 Upstream your kernel patches to the kernel community (recommended). openEuler will synchronize with the kernel master in a timely manner.
Step 6 Sign your work - the Developer’s Certificate of Origin.
Similar to the upstream kernel community, you also need to sign your patch.
For details, see https://www.kernel.org/doc/html/latest/process/submitting-patches.html.
The sign-off is a simple line at the end of the explanation of the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open source patch. The rules are pretty simple. You can certify as below:
Developer’s Certificate of Origin 1.1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file;
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file;
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Then you add a line saying:
Signed-off-by: Random J Developer random@developer.example.org
Use your real name (sorry, no pseudonyms or anonymous contributions).
Use the unified patch format
Reasons:
openEuler will merge massive patches. If all patches are merged by casual
changelog formats without a unified format, the git logs will be messy, and
then it is hard to figure out the original patches.
We definitely will upgrade our openEuler kernel in someday, so strict patch management
will alleviate the pain to migrate patches during big upgrades.
Keyword highlighting is necessary for script parsing.
Define the patch format
[M] stands for “mandatory”.
[O] stands for “option”.
categorycanbe:bugpreparation,bugfix,perf,feature,doc,other...Ifcategoryisfeature,weneedtoaddafeaturenameasbelow:‘‘‘cppcategory:featurefeature:YYY(thefeaturename)‘‘‘IfthepatchisrelatedtoCVEorbugzilla,weneedtoaddthecorrespondingtagasbelow(Ingeneral,itshouldincludeatleastoneofthefollowing):‘‘‘cppCVE:cve-id bugzilla: $bug-id
Examples
Email client - Thunderbird settings
If you are a new developer in the kernel community, it is highly recommended that you use the Thunderbird mail client.
Obtain the English version of Thunderbird from [http://www.mozilla.org/](/p24137568/kernel/tree/openEuler-1.0-LTS/ http:/www.mozilla.org) and install it on your system.
Download URL: https://www.thunderbird.net/en-US/thunderbird/all/
Settings
1 Use the plain text format instead of the HTML format.
Choose Options > Account Settings > Composition & Addressing, and do NOT select Compose message in HTML format.
2 Editor settings
Tools > Options> Advanced > Config editor
- To bring up the Thunderbird’s registry editor, set mailnews.send_plaintext_flowed to false.
- Disable HTML Format: Set mail.identity.id1.compose_html to false.
- Enable UTF-8: Set prefs.converted-to-utf8 to true.
- View messages in UTF-8: Set mailnews.view_default_charset to UTF-8.
- Set mailnews.wraplength to 9999 to avoid auto-wrap.
Linux kernel
There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. Please read Documentation/admin-guide/README.rst first.
In order to build the documentation, use
make htmldocs
ormake pdfdocs
. The formatted documentation can also be read online at:There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file.
Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.