Lines Matching +full:in +full:- +full:kernel
5 -----------------
7 The rest of this section covers the scope of the kernel development process
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.
15 :ref:`development_process` introduces the development process, the kernel
16 release cycle, and the mechanics of the merge window. The various phases in
19 with kernel development are encouraged to track down and fix bugs as an
22 :ref:`development_early_stage` covers early-stage project planning, with an
28 which can help to ensure that kernel patches are correct.
33 Following the advice in this section should help to ensure the best
46 for more information on kernel development.
49 ---------------------------
51 The Linux kernel, at over 8 million lines of code and well over 1000
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
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
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
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
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
79 Working with the kernel development community is not especially hard. But,
81 difficulties when trying to do kernel work. The kernel community has
83 smoothly (and produce a high-quality product) in an environment where
85 surprising that Linux kernel development process differs greatly from
88 The kernel's development process may come across as strange and
90 experience behind it. A developer who does not understand the kernel
92 have a frustrating experience in store. The development community, while
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 -
104 -------
116 ------------------------------------------------
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,
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:
130 - Code which has been merged into the mainline kernel is available to all
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
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
143 out-of-tree code requires significant amounts of work just to keep that
146 Code which is in the mainline, instead, does not require this work as the
152 - Beyond that, code which is in the kernel will often be improved by other
156 - Kernel code is subjected to review, both before and after merging into
158 this review process invariably finds ways in which the code can be
160 especially true for code which has been developed in a closed
162 developers. Out-of-tree code is lower-quality code.
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.
169 - When code is maintained separately, the possibility that a third party
172 harder - to the point of impossibility. Then you will be faced with the
175 users over to the in-tree version.
177 - Contribution of code is the fundamental action which makes the whole
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
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.
188 before considering any sort of binary-only kernel code distribution. These
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
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
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
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
211 kernel.
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
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
225 point, vendors whose code is in the mainline and well maintained will be
229 ---------
231 Code is contributed to the Linux kernel under a number of licenses, but all
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
236 versions of the GPL) or the three-clause BSD license. Any contributions
238 kernel.
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.
245 the licensing of the kernel is doomed to almost certain failure. There are
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
251 It is imperative that all code contributed to the kernel be legitimately
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
260 Questions about copyright-related issues are common on Linux development
262 answers, but one should bear in mind that the people answering those