Lines Matching refs:code

17 encounter there.  There are a great many reasons why kernel code should be
59 The Linux kernel, at over 8 million lines of code and well over 1000
92 thousands of lines of code are being changed every day.  So it is not
127 learning how to work with the kernel community and get their code into the
130 contributing code can look like an avoidable expense; it seems easier to
131 just keep the code separate and support users directly.  The truth of the
132 matter is that keeping code separate ("out of tree") is a false economy.
134 As a way of illustrating the costs of out-of-tree code, here are a few
148   improvements to be made at any time and results in higher-quality code.
149   But one result of that policy is that any out-of-tree code requires
151   out-of-tree code requires significant amounts of work just to keep that
152   code working.
156   to also fix any code that breaks as the result of that change.  So code
160 - Beyond that, code which is in the kernel will often be improved by other
164 - Kernel code is subjected to review, both before and after merging into
166   this review process invariably finds ways in which the code can be
168   especially true for code which has been developed in a closed
169   environment; such code benefits strongly from review by outside
170   developers.  Out-of-tree code is lower-quality code.
177 - When code is maintained separately, the possibility that a third party
179   exists.  Should that happen, getting your code merged will become much
182   out of tree indefinitely, or (2) abandoning your code and migrating your
185 - Contribution of code is the fundamental action which makes the whole
186   process work.  By contributing your code you can add new functionality to
188   other kernel developers.  If you have developed code for Linux (or are
190   success of this platform; contributing code is one of the best ways to
193 All of the reasoning above applies to any out-of-tree kernel code,
194 including code which is distributed in proprietary, binary-only form.
196 before considering any sort of binary-only kernel code distribution.  These
221 - Everything that was said above about code review applies doubly to
222   closed-source code.  Since this code is not available at all, it cannot
230 widespread code review and the value of allowing your users to add
233 point, vendors whose code is in the mainline and well maintained will be
240 code must be compatible with version 2 of the GNU General Public License
242 In practice, that means that all code contributions are covered either by
248 Copyright assignments are not required (or requested) for code contributed
249 to the kernel.  All code merged into the mainline kernel retains its
255 be obtained (or their code removed from the kernel).  So, in particular,
259 It is imperative that all code contributed to the kernel be legitimately
260 free software.  For that reason, code from anonymous (or pseudonymous)
262 off" on their code, stating that the code can be distributed with the
265 kernel (such as code which derives from reverse-engineering efforts lacking
272 legal questions relating to Linux source code, there is no substitute for