Lines Matching refs:kernel
3 Linux kernel development in the early 1990's was a pretty loose affair,
6 course of one year, the kernel has since had to evolve a number of
13 The kernel developers use a loosely time-based release process, with a new
14 major kernel release happening every two or three months. The recent
24 Every 2.6.x release is a major kernel release with new features, internal
27 thus the leading edge of Linux kernel development; the kernel uses a
34 community) is merged into the mainline kernel. The bulk of changes for a
46 first of the "rc" kernels. For the kernel which is destined to be 2.6.40,
50 kernel has begun.
64 will get up to somewhere between -rc6 and -rc9 before the kernel is
104 next development kernel. Kernels will typically receive stable updates for
106 for example, the 2.6.36 kernel's history looked like:
120 2.6.27 Willy Tarreau (Deep-frozen stable kernel)
122 2.6.35 Andi Kleen (Embedded flag kernel)
124 The selection of a kernel for long-term support is purely a matter of a
133 kernel. There is, instead, a somewhat involved (if somewhat informal)
142 a patch gets into the kernel. What follows below is an introduction which
174 in updating the patch to the current kernel so that it applies cleanly
193 One of the largest mistakes made by kernel developers (or their employers)
201 There is exactly one person who can merge patches into the mainline kernel
203 into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus
204 himself. The kernel project has long since grown to a size where no single
206 way the kernel developers have addressed this growth is through the use of
209 The kernel code base is logically broken down into a set of subsystems:
214 of the kernel they manage; they are the ones who will (usually) accept a
215 patch for inclusion into the mainline kernel.
217 Subsystem maintainers each manage their own version of the kernel source
227 becoming part of the mainline kernel. The amount of attention that Linus
240 Clearly, in a system like this, getting patches into the kernel depends on
247 The chain of subsystem trees guides the flow of patches into the kernel,
252 core kernel function prototype, for example, will conflict with any other
255 changes land in the mainline kernel. One could pull changes from all of
267 mailing list, or they may apply to a part of the kernel for which there is
287 Linux-next trees are announced on the linux-kernel and linux-next mailing
290 http://www.kernel.org/pub/linux/kernel/next/
292 Linux-next has become an integral part of the kernel development process;
299 The kernel source tree contains the drivers/staging/ directory, where
301 being added to the kernel tree live. They remain in drivers/staging while
303 kernel proper. This is a way to keep track of drivers that aren't
304 up to Linux kernel coding or quality standards, but people may want to use
311 the pending work that the driver needs for acceptance into the kernel
327 As can be seen from the above text, the kernel development process depends
334 By far the dominant source code management system used by the kernel
337 for kernel development, in that it performs quite well when dealing with
340 time. Some sort of familiarity with git is almost a requirement for kernel
351 Among the kernel developers who do not use git, the most popular choice is
373 A great deal of Linux kernel development work is done by way of mailing
380 Most kernel mailing lists are run on vger.kernel.org; the master list can
383 http://vger.kernel.org/vger-lists.html
388 The core mailing list for kernel development is, of course, linux-kernel.
392 degree of politeness. But there is no other place where the kernel
396 There are a few hints which can help with linux-kernel survival:
411 - When responding to linux-kernel email (or that on other lists) preserve
426 - Ask on the correct mailing list. Linux-kernel may be the general meeting
432 question on linux-kernel will almost certainly receive a polite suggestion
436 in the MAINTAINERS file packaged with the kernel source.
441 Questions about how to get started with the kernel development process are
448 kernel developers. It is possible to bring in-house developers up to speed
449 on Linux kernel development, given the investment of a bit of time. Taking
451 the kernel and the company both, and who can help to train others as well.
464 Andrew Morton gives this advice for aspiring kernel developers
466 The #1 project for all kernel beginners should surely be "make sure
467 that the kernel runs perfectly at all times on all machines which
470 persistence!) but that's fine - it's a part of kernel development.