]>
Commit | Line | Data |
---|---|---|
7d56f0fa S |
1 | Introduction |
2 | ============ | |
75b02146 | 3 | |
f7c9fe4b MCC |
4 | Executive summary |
5 | ----------------- | |
75b02146 JC |
6 | |
7 | The rest of this section covers the scope of the kernel development process | |
8 | and the kinds of frustrations that developers and their employers can | |
9 | encounter there. There are a great many reasons why kernel code should be | |
10 | merged into the official ("mainline") kernel, including automatic | |
11 | availability to users, community support in many forms, and the ability to | |
12 | influence the direction of kernel development. Code contributed to the | |
13 | Linux kernel must be made available under a GPL-compatible license. | |
14 | ||
f7c9fe4b MCC |
15 | :ref:`development_process` introduces the development process, the kernel |
16 | release cycle, and the mechanics of the merge window. The various phases in | |
17 | the patch development, review, and merging cycle are covered. There is some | |
75b02146 JC |
18 | discussion of tools and mailing lists. Developers wanting to get started |
19 | with kernel development are encouraged to track down and fix bugs as an | |
20 | initial exercise. | |
21 | ||
f7c9fe4b MCC |
22 | :ref:`development_early_stage` covers early-stage project planning, with an |
23 | emphasis on involving the development community as soon as possible. | |
75b02146 | 24 | |
f7c9fe4b MCC |
25 | :ref:`development_coding` is about the coding process; several pitfalls which |
26 | have been encountered by other developers are discussed. Some requirements for | |
75b02146 JC |
27 | patches are covered, and there is an introduction to some of the tools |
28 | which can help to ensure that kernel patches are correct. | |
29 | ||
f7c9fe4b MCC |
30 | :ref:`development_posting` talks about the process of posting patches for |
31 | review. To be taken seriously by the development community, patches must be | |
32 | properly formatted and described, and they must be sent to the right place. | |
75b02146 JC |
33 | Following the advice in this section should help to ensure the best |
34 | possible reception for your work. | |
35 | ||
f7c9fe4b MCC |
36 | :ref:`development_followthrough` covers what happens after posting patches; the |
37 | job is far from done at that point. Working with reviewers is a crucial part | |
38 | of the development process; this section offers a number of tips on how to | |
39 | avoid problems at this important stage. Developers are cautioned against | |
75b02146 JC |
40 | assuming that the job is done when a patch is merged into the mainline. |
41 | ||
f7c9fe4b MCC |
42 | :ref:`development_advancedtopics` introduces a couple of "advanced" topics: |
43 | managing patches with git and reviewing patches posted by others. | |
75b02146 | 44 | |
f7c9fe4b MCC |
45 | :ref:`development_conclusion` concludes the document with pointers to sources |
46 | for more information on kernel development. | |
75b02146 | 47 | |
f7c9fe4b MCC |
48 | What this document is about |
49 | --------------------------- | |
75b02146 | 50 | |
5c050fb9 JC |
51 | The Linux kernel, at over 8 million lines of code and well over 1000 |
52 | contributors to each release, is one of the largest and most active free | |
53 | software projects in existence. Since its humble beginning in 1991, this | |
54 | kernel has evolved into a best-of-breed operating system component which | |
55 | runs on pocket-sized digital music players, desktop PCs, the largest | |
56 | supercomputers in existence, and all types of systems in between. It is a | |
57 | robust, efficient, and scalable solution for almost any situation. | |
75b02146 JC |
58 | |
59 | With the growth of Linux has come an increase in the number of developers | |
60 | (and companies) wishing to participate in its development. Hardware | |
61 | vendors want to ensure that Linux supports their products well, making | |
62 | those products attractive to Linux users. Embedded systems vendors, who | |
63 | use Linux as a component in an integrated product, want Linux to be as | |
64 | capable and well-suited to the task at hand as possible. Distributors and | |
65 | other software vendors who base their products on Linux have a clear | |
66 | interest in the capabilities, performance, and reliability of the Linux | |
67 | kernel. And end users, too, will often wish to change Linux to make it | |
68 | better suit their needs. | |
69 | ||
70 | One of the most compelling features of Linux is that it is accessible to | |
71 | these developers; anybody with the requisite skills can improve Linux and | |
72 | influence the direction of its development. Proprietary products cannot | |
73 | offer this kind of openness, which is a characteristic of the free software | |
74 | process. But, if anything, the kernel is even more open than most other | |
75 | free software projects. A typical three-month kernel development cycle can | |
76 | involve over 1000 developers working for more than 100 different companies | |
77 | (or for no company at all). | |
78 | ||
79 | Working with the kernel development community is not especially hard. But, | |
80 | that notwithstanding, many potential contributors have experienced | |
81 | difficulties when trying to do kernel work. The kernel community has | |
82 | evolved its own distinct ways of operating which allow it to function | |
83 | smoothly (and produce a high-quality product) in an environment where | |
84 | thousands of lines of code are being changed every day. So it is not | |
85 | surprising that Linux kernel development process differs greatly from | |
86 | proprietary development methods. | |
87 | ||
88 | The kernel's development process may come across as strange and | |
89 | intimidating to new developers, but there are good reasons and solid | |
90 | experience behind it. A developer who does not understand the kernel | |
91 | community's ways (or, worse, who tries to flout or circumvent them) will | |
92 | have a frustrating experience in store. The development community, while | |
93 | being helpful to those who are trying to learn, has little time for those | |
94 | who will not listen or who do not care about the development process. | |
95 | ||
96 | It is hoped that those who read this document will be able to avoid that | |
97 | frustrating experience. There is a lot of material here, but the effort | |
98 | involved in reading it will be repaid in short order. The development | |
99 | community is always in need of developers who will help to make the kernel | |
100 | better; the following text should help you - or those who work for you - | |
101 | join our community. | |
102 | ||
f7c9fe4b MCC |
103 | Credits |
104 | ------- | |
75b02146 JC |
105 | |
106 | This document was written by Jonathan Corbet, corbet@lwn.net. It has been | |
107 | improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland | |
108 | Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, | |
109 | Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and | |
5c050fb9 | 110 | Jochen Voß. |
75b02146 JC |
111 | |
112 | This work was supported by the Linux Foundation; thanks especially to | |
113 | Amanda McPherson, who saw the value of this effort and made it all happen. | |
114 | ||
f7c9fe4b MCC |
115 | The importance of getting code into the mainline |
116 | ------------------------------------------------ | |
75b02146 JC |
117 | |
118 | Some companies and developers occasionally wonder why they should bother | |
119 | learning how to work with the kernel community and get their code into the | |
120 | mainline kernel (the "mainline" being the kernel maintained by Linus | |
121 | Torvalds and used as a base by Linux distributors). In the short term, | |
122 | contributing code can look like an avoidable expense; it seems easier to | |
123 | just keep the code separate and support users directly. The truth of the | |
124 | matter is that keeping code separate ("out of tree") is a false economy. | |
125 | ||
126 | As a way of illustrating the costs of out-of-tree code, here are a few | |
127 | relevant aspects of the kernel development process; most of these will be | |
128 | discussed in greater detail later in this document. Consider: | |
129 | ||
130 | - Code which has been merged into the mainline kernel is available to all | |
131 | Linux users. It will automatically be present on all distributions which | |
132 | enable it. There is no need for driver disks, downloads, or the hassles | |
133 | of supporting multiple versions of multiple distributions; it all just | |
134 | works, for the developer and for the user. Incorporation into the | |
135 | mainline solves a large number of distribution and support problems. | |
136 | ||
137 | - While kernel developers strive to maintain a stable interface to user | |
138 | space, the internal kernel API is in constant flux. The lack of a stable | |
139 | internal interface is a deliberate design decision; it allows fundamental | |
140 | improvements to be made at any time and results in higher-quality code. | |
141 | But one result of that policy is that any out-of-tree code requires | |
142 | constant upkeep if it is to work with new kernels. Maintaining | |
143 | out-of-tree code requires significant amounts of work just to keep that | |
144 | code working. | |
145 | ||
146 | Code which is in the mainline, instead, does not require this work as the | |
147 | result of a simple rule requiring any developer who makes an API change | |
148 | to also fix any code that breaks as the result of that change. So code | |
149 | which has been merged into the mainline has significantly lower | |
150 | maintenance costs. | |
151 | ||
152 | - Beyond that, code which is in the kernel will often be improved by other | |
153 | developers. Surprising results can come from empowering your user | |
154 | community and customers to improve your product. | |
155 | ||
156 | - Kernel code is subjected to review, both before and after merging into | |
157 | the mainline. No matter how strong the original developer's skills are, | |
158 | this review process invariably finds ways in which the code can be | |
159 | improved. Often review finds severe bugs and security problems. This is | |
160 | especially true for code which has been developed in a closed | |
161 | environment; such code benefits strongly from review by outside | |
162 | developers. Out-of-tree code is lower-quality code. | |
163 | ||
164 | - Participation in the development process is your way to influence the | |
165 | direction of kernel development. Users who complain from the sidelines | |
166 | are heard, but active developers have a stronger voice - and the ability | |
167 | to implement changes which make the kernel work better for their needs. | |
168 | ||
169 | - When code is maintained separately, the possibility that a third party | |
170 | will contribute a different implementation of a similar feature always | |
171 | exists. Should that happen, getting your code merged will become much | |
172 | harder - to the point of impossibility. Then you will be faced with the | |
173 | unpleasant alternatives of either (1) maintaining a nonstandard feature | |
174 | out of tree indefinitely, or (2) abandoning your code and migrating your | |
175 | users over to the in-tree version. | |
176 | ||
177 | - Contribution of code is the fundamental action which makes the whole | |
178 | process work. By contributing your code you can add new functionality to | |
179 | the kernel and provide capabilities and examples which are of use to | |
180 | other kernel developers. If you have developed code for Linux (or are | |
181 | thinking about doing so), you clearly have an interest in the continued | |
182 | success of this platform; contributing code is one of the best ways to | |
183 | help ensure that success. | |
184 | ||
185 | All of the reasoning above applies to any out-of-tree kernel code, | |
186 | including code which is distributed in proprietary, binary-only form. | |
187 | There are, however, additional factors which should be taken into account | |
188 | before considering any sort of binary-only kernel code distribution. These | |
189 | include: | |
190 | ||
191 | - The legal issues around the distribution of proprietary kernel modules | |
192 | are cloudy at best; quite a few kernel copyright holders believe that | |
193 | most binary-only modules are derived products of the kernel and that, as | |
194 | a result, their distribution is a violation of the GNU General Public | |
195 | license (about which more will be said below). Your author is not a | |
196 | lawyer, and nothing in this document can possibly be considered to be | |
197 | legal advice. The true legal status of closed-source modules can only be | |
198 | determined by the courts. But the uncertainty which haunts those modules | |
199 | is there regardless. | |
200 | ||
201 | - Binary modules greatly increase the difficulty of debugging kernel | |
202 | problems, to the point that most kernel developers will not even try. So | |
203 | the distribution of binary-only modules will make it harder for your | |
204 | users to get support from the community. | |
205 | ||
206 | - Support is also harder for distributors of binary-only modules, who must | |
207 | provide a version of the module for every distribution and every kernel | |
208 | version they wish to support. Dozens of builds of a single module can | |
209 | be required to provide reasonably comprehensive coverage, and your users | |
210 | will have to upgrade your module separately every time they upgrade their | |
211 | kernel. | |
212 | ||
213 | - Everything that was said above about code review applies doubly to | |
214 | closed-source code. Since this code is not available at all, it cannot | |
215 | have been reviewed by the community and will, beyond doubt, have serious | |
5c050fb9 | 216 | problems. |
75b02146 JC |
217 | |
218 | Makers of embedded systems, in particular, may be tempted to disregard much | |
219 | of what has been said in this section in the belief that they are shipping | |
220 | a self-contained product which uses a frozen kernel version and requires no | |
221 | more development after its release. This argument misses the value of | |
222 | widespread code review and the value of allowing your users to add | |
223 | capabilities to your product. But these products, too, have a limited | |
224 | commercial life, after which a new version must be released. At that | |
225 | point, vendors whose code is in the mainline and well maintained will be | |
226 | much better positioned to get the new product ready for market quickly. | |
227 | ||
f7c9fe4b MCC |
228 | Licensing |
229 | --------- | |
75b02146 JC |
230 | |
231 | Code is contributed to the Linux kernel under a number of licenses, but all | |
232 | code must be compatible with version 2 of the GNU General Public License | |
233 | (GPLv2), which is the license covering the kernel distribution as a whole. | |
234 | In practice, that means that all code contributions are covered either by | |
235 | GPLv2 (with, optionally, language allowing distribution under later | |
236 | versions of the GPL) or the three-clause BSD license. Any contributions | |
237 | which are not covered by a compatible license will not be accepted into the | |
238 | kernel. | |
239 | ||
240 | Copyright assignments are not required (or requested) for code contributed | |
241 | to the kernel. All code merged into the mainline kernel retains its | |
242 | original ownership; as a result, the kernel now has thousands of owners. | |
243 | ||
244 | One implication of this ownership structure is that any attempt to change | |
245 | the licensing of the kernel is doomed to almost certain failure. There are | |
246 | few practical scenarios where the agreement of all copyright holders could | |
247 | be obtained (or their code removed from the kernel). So, in particular, | |
248 | there is no prospect of a migration to version 3 of the GPL in the | |
249 | foreseeable future. | |
250 | ||
251 | It is imperative that all code contributed to the kernel be legitimately | |
252 | free software. For that reason, code from anonymous (or pseudonymous) | |
253 | contributors will not be accepted. All contributors are required to "sign | |
254 | off" on their code, stating that the code can be distributed with the | |
255 | kernel under the GPL. Code which has not been licensed as free software by | |
256 | its owner, or which risks creating copyright-related problems for the | |
257 | kernel (such as code which derives from reverse-engineering efforts lacking | |
258 | proper safeguards) cannot be contributed. | |
259 | ||
260 | Questions about copyright-related issues are common on Linux development | |
261 | mailing lists. Such questions will normally receive no shortage of | |
262 | answers, but one should bear in mind that the people answering those | |
263 | questions are not lawyers and cannot provide legal advice. If you have | |
264 | legal questions relating to Linux source code, there is no substitute for | |
265 | talking with a lawyer who understands this field. Relying on answers | |
266 | obtained on technical mailing lists is a risky affair. |