Lines Matching full:code

9 encounter there.  There are a great many reasons why kernel code should be
12 influence the direction of kernel development.  Code contributed to the
51 The Linux kernel, at over 8 million lines of code and well over 1000
84 thousands of lines of code are being changed every day.  So it is not
115 The importance of getting code into the mainline
119 learning how to work with the kernel community and get their code into the
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.
126 As a way of illustrating the costs of out-of-tree code, here are a few
130 - Code which has been merged into the mainline kernel is available to all
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
144   code working.
146   Code which is in the mainline, instead, does not require this work as the
148   to also fix any code that breaks as the result of that change.  So code
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
161   environment; such code benefits strongly from review by outside
162   developers.  Out-of-tree code is lower-quality code.
169 - When code is maintained separately, the possibility that a third party
171   exists.  Should that happen, getting your code merged will become much
174   out of tree indefinitely, or (2) abandoning your code and migrating your
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
180   other kernel developers.  If you have developed code for Linux (or are
182   success of this platform; contributing code is one of the best ways to
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
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
222 widespread code review and the value of allowing your users to add
225 point, vendors whose code is in the mainline and well maintained will be
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
234 In practice, that means that all code contributions are covered either by
240 Copyright assignments are not required (or requested) for code contributed
241 to the kernel.  All code merged into the mainline kernel retains its
247 be obtained (or their code removed from the kernel).  So, in particular,
251 It is imperative that all code contributed to the kernel be legitimately
252 free software.  For that reason, code from anonymous (or pseudonymous)
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
257 kernel (such as code which derives from reverse-engineering efforts lacking
264 legal questions relating to Linux source code, there is no substitute for