Lines Matching full:code
11 encounter there. There are a great many reasons why kernel code should be
14 influence the direction of kernel development. Code contributed to the
53 The Linux kernel, at over 8 million lines of code and well over 1000
86 thousands of lines of code are being changed every day. So it is not
117 The importance of getting code into the mainline
121 learning how to work with the kernel community and get their code into the
124 contributing code can look like an avoidable expense; it seems easier to
125 just keep the code separate and support users directly. The truth of the
126 matter is that keeping code separate ("out of tree") is a false economy.
128 As a way of illustrating the costs of out-of-tree code, here are a few
132 - Code which has been merged into the mainline kernel is available to all
142 improvements to be made at any time and results in higher-quality code.
143 But one result of that policy is that any out-of-tree code requires
145 out-of-tree code requires significant amounts of work just to keep that
146 code working.
148 Code which is in the mainline, instead, does not require this work as the
150 to also fix any code that breaks as the result of that change. So code
154 - Beyond that, code which is in the kernel will often be improved by other
158 - Kernel code is subjected to review, both before and after merging into
160 this review process invariably finds ways in which the code can be
162 especially true for code which has been developed in a closed
163 environment; such code benefits strongly from review by outside
164 developers. Out-of-tree code is lower-quality code.
171 - When code is maintained separately, the possibility that a third party
173 exists. Should that happen, getting your code merged will become much
176 out of tree indefinitely, or (2) abandoning your code and migrating your
179 - Contribution of code is the fundamental action which makes the whole
180 process work. By contributing your code you can add new functionality to
182 other kernel developers. If you have developed code for Linux (or are
184 success of this platform; contributing code is one of the best ways to
187 All of the reasoning above applies to any out-of-tree kernel code,
188 including code which is distributed in proprietary, binary-only form.
190 before considering any sort of binary-only kernel code distribution. These
215 - Everything that was said above about code review applies doubly to
216 closed-source code. Since this code is not available at all, it cannot
224 widespread code review and the value of allowing your users to add
227 point, vendors whose code is in the mainline and well maintained will be
233 Code is contributed to the Linux kernel under a number of licenses, but all
234 code must be compatible with version 2 of the GNU General Public License
236 In practice, that means that all code contributions are covered either by
242 Copyright assignments are not required (or requested) for code contributed
243 to the kernel. All code merged into the mainline kernel retains its
249 be obtained (or their code removed from the kernel). So, in particular,
253 It is imperative that all code contributed to the kernel be legitimately
254 free software. For that reason, code from anonymous (or pseudonymous)
256 off" on their code, stating that the code can be distributed with the
257 kernel under the GPL. Code which has not been licensed as free software by
259 kernel (such as code which derives from reverse-engineering efforts lacking
266 legal questions relating to Linux source code, there is no substitute for