-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
282 lines (203 loc) · 9 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
Contributions to OpenHarmony linux kernel project
==========================================
Sign DCO
--------
Before submitting any Contributions to OpenHarmony kernel, you have to sign
DCO.
See:
https://dco.openharmony.io/sign-dco
Steps of submitting patches
---------------------------
1. Compile and test your patches successfully.
You should test your patch in OpenHamrony supported boards, hi3516dv300,
etc.
2. Generate patches
Your patches should be based on top of latest OpenHarmony branch, and
should use git-format-patch to generate patches, and if it's a patchset,
it's better to use --cover-letter option to describe what the patchset
does.
Using scripts/checkpatch.pl to make sure there's no coding style issue.
And make sure your patch follow unified OpenHarmony patch format describe
below.
*Tips*: Learn more about linux kernel coding style
en:
https://gitee.com/openharmony/kernel_linux/blob/master/Documentation/process/coding-style.rst
zh:
https://gitee.com/openharmony/kernel_linux/blob/master/Documentation/translations/zh_CN/coding-style.rst
3. Send patch to OpenHarmony mailing list
Use this command to send patches to OpenHarmony kernel mailing list:
git send-email *.patch -to="[email protected]" --suppress-cc=all
*NOTE*: that you must add --suppress-cc=all if you use git send-email,
otherwise the email will be cced to the people in upstream community and
mailing lists.
*Tips*: Subscribe the mailing list
https://lists.openatom.io/postorius/lists/kernel.openharmony.io/
*See*: How to send patches using git-send-email
https://git-scm.com/docs/git-send-email
4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions
to send out.
Use --subject-prefix="PATCH v2" option to add v2 tag for 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
5. Upstream your kernel patch to kernel community is strongly recommended.
OpenHarmony will sync up with kernel master timely.
6. Sign your work - the Developer's Certificate of Origin
As the same of upstream kernel community, you also need to sign your
patch.
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 for 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: if you
can certify the 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; or
(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; or
(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 just add a line saying:
Signed-off-by: Random J Developer <[email protected]>
using your real name (sorry, no pseudonyms or anonymous contributions.)
Use unified patch format
------------------------
Reasons:
1. long term maintainability
OpenHarmony will merge massive patches. If all patches are merged by
casual changelog format without a unified format, the git log will be
messy, and then it's hard to figure out the original patch.
2. kernel upgrade
We definitely will upgrade our OpenHarmony kernel in someday, using
strict patch management will alleviate the pain to migrate patches
during big upgrade.
3. easy for script parsing
Keyword highlighting is necessary for script parsing.
Patch format definition
-----------------------
[M] stands for "mandatory"
[O] stands for "option"
$category can be: bug preparation, bugfix, perf, feature, doc, other...
If category is feature, then we also need to add feature name like below:
category: feature
feature: YYY (the feature name)
If the patch is related to CVE or issue/bugzilla, then we need add the
corresponding tag like below (In general, it should include at least one
of the following):
CVE: $cve-id or NA
issue: $issue-id or NA
bugzilla: $bug-id or NA
issue: https://gitee.com/openharmony/kernel_linux/issues
Additional changelog should include at least one of the flollwing:
1) Why we should apply this patch
2) What real problem in 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 detail information is very useful for porting patch to another kenrel
branch.
1. stable patch
stable inclusion [M]
from $stable-version [M]
commit $id [M]
bugzilla: $bug-id [O]
issue: $issue-id [O]
CVE: $cve-id [O]
additional changelog [O]
--------------------------------
original changelog
Signed-off-by: $your_name <$your_mail> [M]
($stable-version would be stable-4.19.156, stable-4.19.157, etc...
$id would be stable commit)
2. mainline patch:
mainline inclusion [M]
from $mainline-version [M]
commit $id [M]
category: $category [M]
bugzilla: $bug-id [O]
issue: $issue-id [O]
CVE: $cve-id [O]
additional changelog [O]
--------------------------------
original changelog
Signed-off-by: $your_name <$your_mail> [M]
($mainline-version could be mainline-5.6, mainline-5.10, etc...
$id would be mainline commit)
3. ohos patch
ohos inclusion [M]
category: $category [M]
bugzilla: $bug-id or NA [O]
issue: $issue-id or NA [O]
CVE: $cve-id or NA [O]
--------------------------------
changelog
Signed-off-by: $your_name <$your_mail> [M]
Examples
--------
mainline inclusion
from mainline-4.10
commit 0becc0ae5b42828785b589f686725ff5bc3b9b25
category: bugfix
issue: 1000
CVE: NA
The patch fixes a BUG_ON in the product: injecting single bit ECC error
to memory before system boot use hardware inject tools, which 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 <[email protected]>
Tested-by: Li Si <[email protected]>
Email Client - Thunderbird Settings
-----------------------------------
If you are newly developer in the kernel community, it is highly recommended
to use thunderbird mail client.
1. Thunderbird Installation
Get English version Thunderbird from http://www.mozilla.org/ and install
it on your system.
Download url: https://www.thunderbird.net/en-US/thunderbird/all/
2. Settings
2.1 Use plain text format instead of HTML format
Options -> Account Settings -> Composition & Addressing, do *NOT*
select "Compose message in HTML format".
2.2 Editor Settings
Tools->Options->Advanced->Config editor.
- To bring up the thunderbird's registry editor, and set:
"mailnews.send_plaintext_flowed" to "false".
- Disable HTML Format: Set "mail.identity.id1.compose_html" to
"false".
- Enable UTF8: Set "prefs.converted-to-utf8" to "true".
- View message in UTF-8: Set "mailnews.view_default_charset" to
"UTF-8".
- Set mailnews.wraplength to 9999 for avoiding 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.
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.