Lines Matching refs:of
3 The purpose of this document is to help developers (and their managers)
4 work with the development community with a minimum of frustration. It is
9 discussion which does not require a deep knowledge of kernel programming to
15 The rest of this section covers the scope of the kernel development process
16 and the kinds of frustrations that developers and their employers can
20 influence the direction of kernel development. Code contributed to the
24 the mechanics of the merge window. The various phases in the patch
26 discussion of tools and mailing lists. Developers wanting to get started
35 patches are covered, and there is an introduction to some of the tools
38 Section 5 talks about the process of posting patches for review. To be
45 done at that point. Working with reviewers is a crucial part of the
46 development process; this section offers a number of tips on how to avoid
50 Section 7 introduces a couple of "advanced" topics: managing patches with
59 The Linux kernel, at over 8 million lines of code and well over 1000
60 contributors to each release, is one of the largest and most active free
62 kernel has evolved into a best-of-breed operating system component which
64 supercomputers in existence, and all types of systems in between. It is a
67 With the growth of Linux has come an increase in the number of developers
74 interest in the capabilities, performance, and reliability of the Linux
78 One of the most compelling features of Linux is that it is accessible to
80 influence the direction of its development. Proprietary products cannot
81 offer this kind of openness, which is a characteristic of the free software
90 evolved its own distinct ways of operating which allow it to function
92 thousands of lines of code are being changed every day. So it is not
105 frustrating experience. There is a lot of material here, but the effort
107 community is always in need of developers who will help to make the kernel
121 Amanda McPherson, who saw the value of this effort and made it all happen.
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
135 relevant aspects of the kernel development process; most of these will be
141 of supporting multiple versions of multiple distributions; it all just
143 mainline solves a large number of distribution and support problems.
146 space, the internal kernel API is in constant flux. The lack of a stable
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
155 result of a simple rule requiring any developer who makes an API change
156 to also fix any code that breaks as the result of that change. So code
170 developers. Out-of-tree code is lower-quality code.
173 direction of kernel development. Users who complain from the sidelines
178 will contribute a different implementation of a similar feature always
180 harder - to the point of impossibility. Then you will be faced with the
181 unpleasant alternatives of either (1) maintaining a nonstandard feature
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
187 the kernel and provide capabilities and examples which are of use to
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,
196 before considering any sort of binary-only kernel code distribution. These
199 - The legal issues around the distribution of proprietary kernel modules
201 most binary-only modules are derived products of the kernel and that, as
202 a result, their distribution is a violation of the GNU General Public
205 legal advice. The true legal status of closed-source modules can only be
209 - Binary modules greatly increase the difficulty of debugging kernel
211 the distribution of binary-only modules will make it harder for your
214 - Support is also harder for distributors of binary-only modules, who must
215 provide a version of the module for every distribution and every kernel
216 version they wish to support. Dozens of builds of a single module can
226 Makers of embedded systems, in particular, may be tempted to disregard much
227 of what has been said in this section in the belief that they are shipping
229 more development after its release. This argument misses the value of
230 widespread code review and the value of allowing your users to add
239 Code is contributed to the Linux kernel under a number of licenses, but all
240 code must be compatible with version 2 of the GNU General Public License
244 versions of the GPL) or the three-clause BSD license. Any contributions
250 original ownership; as a result, the kernel now has thousands of owners.
252 One implication of this ownership structure is that any attempt to change
253 the licensing of the kernel is doomed to almost certain failure. There are
254 few practical scenarios where the agreement of all copyright holders could
256 there is no prospect of a migration to version 3 of the GPL in the
269 mailing lists. Such questions will normally receive no shortage of