1 .. _development_process_intro:
2
3 Introduction
4 ============
5
6 Executive summary
7 -----------------
8
9 The rest of this section covers the scope of t
10 and the kinds of frustrations that developers
11 encounter there. There are a great many reaso
12 merged into the official ("mainline") kernel,
13 availability to users, community support in ma
14 influence the direction of kernel development.
15 Linux kernel must be made available under a GP
16
17 :ref:`development_process` introduces the deve
18 release cycle, and the mechanics of the merge
19 the patch development, review, and merging cyc
20 discussion of tools and mailing lists. Develo
21 with kernel development are encouraged to trac
22 initial exercise.
23
24 :ref:`development_early_stage` covers early-st
25 emphasis on involving the development communit
26
27 :ref:`development_coding` is about the coding
28 have been encountered by other developers are
29 patches are covered, and there is an introduct
30 which can help to ensure that kernel patches a
31
32 :ref:`development_posting` talks about the pro
33 review. To be taken seriously by the developme
34 properly formatted and described, and they mus
35 Following the advice in this section should he
36 possible reception for your work.
37
38 :ref:`development_followthrough` covers what h
39 job is far from done at that point. Working w
40 of the development process; this section offer
41 avoid problems at this important stage. Devel
42 assuming that the job is done when a patch is
43
44 :ref:`development_advancedtopics` introduces a
45 managing patches with git and reviewing patche
46
47 :ref:`development_conclusion` concludes the do
48 for more information on kernel development.
49
50 What this document is about
51 ---------------------------
52
53 The Linux kernel, at over 8 million lines of c
54 contributors to each release, is one of the la
55 software projects in existence. Since its hum
56 kernel has evolved into a best-of-breed operat
57 runs on pocket-sized digital music players, de
58 supercomputers in existence, and all types of
59 robust, efficient, and scalable solution for a
60
61 With the growth of Linux has come an increase
62 (and companies) wishing to participate in its
63 vendors want to ensure that Linux supports the
64 those products attractive to Linux users. Emb
65 use Linux as a component in an integrated prod
66 capable and well-suited to the task at hand as
67 other software vendors who base their products
68 interest in the capabilities, performance, and
69 kernel. And end users, too, will often wish t
70 better suit their needs.
71
72 One of the most compelling features of Linux i
73 these developers; anybody with the requisite s
74 influence the direction of its development. P
75 offer this kind of openness, which is a charac
76 process. But, if anything, the kernel is even
77 free software projects. A typical three-month
78 involve over 1000 developers working for more
79 (or for no company at all).
80
81 Working with the kernel development community
82 that notwithstanding, many potential contribut
83 difficulties when trying to do kernel work. T
84 evolved its own distinct ways of operating whi
85 smoothly (and produce a high-quality product)
86 thousands of lines of code are being changed e
87 surprising that Linux kernel development proce
88 proprietary development methods.
89
90 The kernel's development process may come acro
91 intimidating to new developers, but there are
92 experience behind it. A developer who does no
93 community's ways (or, worse, who tries to flou
94 have a frustrating experience in store. The d
95 being helpful to those who are trying to learn
96 who will not listen or who do not care about t
97
98 It is hoped that those who read this document
99 frustrating experience. There is a lot of mat
100 involved in reading it will be repaid in short
101 community is always in need of developers who
102 better; the following text should help you - o
103 join our community.
104
105 Credits
106 -------
107
108 This document was written by Jonathan Corbet,
109 improved by comments from Johannes Berg, James
110 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina,
111 Amanda McPherson, Andrew Morton, Andrew Price,
112 Jochen Voß.
113
114 This work was supported by the Linux Foundatio
115 Amanda McPherson, who saw the value of this ef
116
117 The importance of getting code into the mainli
118 ----------------------------------------------
119
120 Some companies and developers occasionally won
121 learning how to work with the kernel community
122 mainline kernel (the "mainline" being the kern
123 Torvalds and used as a base by Linux distribut
124 contributing code can look like an avoidable e
125 just keep the code separate and support users
126 matter is that keeping code separate ("out of
127
128 As a way of illustrating the costs of out-of-t
129 relevant aspects of the kernel development pro
130 discussed in greater detail later in this docu
131
132 - Code which has been merged into the mainline
133 Linux users. It will automatically be prese
134 enable it. There is no need for driver disk
135 of supporting multiple versions of multiple
136 works, for the developer and for the user.
137 mainline solves a large number of distributi
138
139 - While kernel developers strive to maintain a
140 space, the internal kernel API is in constan
141 internal interface is a deliberate design de
142 improvements to be made at any time and resu
143 But one result of that policy is that any ou
144 constant upkeep if it is to work with new ke
145 out-of-tree code requires significant amount
146 code working.
147
148 Code which is in the mainline, instead, does
149 result of a simple rule requiring any develo
150 to also fix any code that breaks as the resu
151 which has been merged into the mainline has
152 maintenance costs.
153
154 - Beyond that, code which is in the kernel wil
155 developers. Surprising results can come fro
156 community and customers to improve your prod
157
158 - Kernel code is subjected to review, both bef
159 the mainline. No matter how strong the orig
160 this review process invariably finds ways in
161 improved. Often review finds severe bugs an
162 especially true for code which has been deve
163 environment; such code benefits strongly fro
164 developers. Out-of-tree code is lower-quali
165
166 - Participation in the development process is
167 direction of kernel development. Users who
168 are heard, but active developers have a stro
169 to implement changes which make the kernel w
170
171 - When code is maintained separately, the poss
172 will contribute a different implementation o
173 exists. Should that happen, getting your co
174 harder - to the point of impossibility. The
175 unpleasant alternatives of either (1) mainta
176 out of tree indefinitely, or (2) abandoning
177 users over to the in-tree version.
178
179 - Contribution of code is the fundamental acti
180 process work. By contributing your code you
181 the kernel and provide capabilities and exam
182 other kernel developers. If you have develo
183 thinking about doing so), you clearly have a
184 success of this platform; contributing code
185 help ensure that success.
186
187 All of the reasoning above applies to any out-
188 including code which is distributed in proprie
189 There are, however, additional factors which s
190 before considering any sort of binary-only ker
191 include:
192
193 - The legal issues around the distribution of
194 are cloudy at best; quite a few kernel copyr
195 most binary-only modules are derived product
196 a result, their distribution is a violation
197 license (about which more will be said below
198 lawyer, and nothing in this document can pos
199 legal advice. The true legal status of clos
200 determined by the courts. But the uncertain
201 is there regardless.
202
203 - Binary modules greatly increase the difficul
204 problems, to the point that most kernel deve
205 the distribution of binary-only modules will
206 users to get support from the community.
207
208 - Support is also harder for distributors of b
209 provide a version of the module for every di
210 version they wish to support. Dozens of bui
211 be required to provide reasonably comprehens
212 will have to upgrade your module separately
213 kernel.
214
215 - Everything that was said above about code re
216 closed-source code. Since this code is not
217 have been reviewed by the community and will
218 problems.
219
220 Makers of embedded systems, in particular, may
221 of what has been said in this section in the b
222 a self-contained product which uses a frozen k
223 more development after its release. This argu
224 widespread code review and the value of allowi
225 capabilities to your product. But these produ
226 commercial life, after which a new version mus
227 point, vendors whose code is in the mainline a
228 much better positioned to get the new product
229
230 Licensing
231 ---------
232
233 Code is contributed to the Linux kernel under
234 code must be compatible with version 2 of the
235 (GPLv2), which is the license covering the ker
236 In practice, that means that all code contribu
237 GPLv2 (with, optionally, language allowing dis
238 versions of the GPL) or the three-clause BSD l
239 which are not covered by a compatible license
240 kernel.
241
242 Copyright assignments are not required (or req
243 to the kernel. All code merged into the mainl
244 original ownership; as a result, the kernel no
245
246 One implication of this ownership structure is
247 the licensing of the kernel is doomed to almos
248 few practical scenarios where the agreement of
249 be obtained (or their code removed from the ke
250 there is no prospect of a migration to version
251 foreseeable future.
252
253 It is imperative that all code contributed to
254 free software. For that reason, code from ano
255 contributors will not be accepted. All contri
256 off" on their code, stating that the code can
257 kernel under the GPL. Code which has not been
258 its owner, or which risks creating copyright-r
259 kernel (such as code which derives from revers
260 proper safeguards) cannot be contributed.
261
262 Questions about copyright-related issues are c
263 mailing lists. Such questions will normally r
264 answers, but one should bear in mind that the
265 questions are not lawyers and cannot provide l
266 legal questions relating to Linux source code,
267 talking with a lawyer who understands this fie
268 obtained on technical mailing lists is a risky
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.