Lines Matching refs:kernel
6 accessible to those who are not intimately familiar with Linux kernel
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
17 encounter there. There are a great many reasons why kernel code should be
18 merged into the official ("mainline") kernel, including automatic
20 influence the direction of kernel development. Code contributed to the
21 Linux kernel must be made available under a GPL-compatible license.
23 Section 2 introduces the development process, the kernel release cycle, and
27 with kernel development are encouraged to track down and fix bugs as an
36 which can help to ensure that kernel patches are correct.
54 information on kernel development.
59 The Linux kernel, at over 8 million lines of code and well over 1000
62 kernel has evolved into a best-of-breed operating system component which
75 kernel. And end users, too, will often wish to change Linux to make it
82 process. But, if anything, the kernel is even more open than most other
83 free software projects. A typical three-month kernel development cycle can
87 Working with the kernel development community is not especially hard. But,
89 difficulties when trying to do kernel work. The kernel community has
93 surprising that Linux kernel development process differs greatly from
96 The kernel's development process may come across as strange and
98 experience behind it. A developer who does not understand the kernel
107 community is always in need of developers who will help to make the kernel
127 learning how to work with the kernel community and get their code into the
128 mainline kernel (the "mainline" being the kernel maintained by Linus
135 relevant aspects of the kernel development process; most of these will be
138 - Code which has been merged into the mainline kernel is available to all
145 - While kernel developers strive to maintain a stable interface to user
146 space, the internal kernel API is in constant flux. The lack of a stable
160 - Beyond that, code which is in the kernel will often be improved by other
173 direction of kernel development. Users who complain from the sidelines
175 to implement changes which make the kernel work better for their needs.
187 the kernel and provide capabilities and examples which are of use to
188 other kernel developers. If you have developed code for Linux (or are
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
200 are cloudy at best; quite a few kernel copyright holders believe that
201 most binary-only modules are derived products of the kernel and that, as
209 - Binary modules greatly increase the difficulty of debugging kernel
210 problems, to the point that most kernel developers will not even try. So
215 provide a version of the module for every distribution and every kernel
219 kernel.
228 a self-contained product which uses a frozen kernel version and requires no
239 Code is contributed to the Linux kernel under a number of licenses, but all
241 (GPLv2), which is the license covering the kernel distribution as a whole.
246 kernel.
249 to the kernel. All code merged into the mainline kernel retains its
250 original ownership; as a result, the kernel now has thousands of owners.
253 the licensing of the kernel is doomed to almost certain failure. There are
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
263 kernel under the GPL. Code which has not been licensed as free software by
265 kernel (such as code which derives from reverse-engineering efforts lacking