| blob | bff3d8c6fd5b0a3d2de551190844156d27c7216b |
1 Introduction to linux kernel development process
2 ================================================
4 (Written by Paolo Ciarrocchi, November 2005)
5 (http://paolo.ciarrocchi.googlepages.com/)
7 Overview
8 --------
9 Linux kernel development process is quite complex and not very well documented
10 so I decided to try to summarize it in the hope to be useful for the community.
11 2.6.x kernels are the base stable releases released by Linus Torvalds.
12 The highest numbered release is the most recent.
13 If regressions or other serious flaws are found then a -stable fix patch
14 will be released (see below) on top of this base. Once a new 2.6.x base kernel is released,
15 a delta between the previous 2.6.x kernel and the new one is made available as a patch
18 2.6.x kernels
19 -------------
21 2.6.x kernels are maintained by Linus Torvalds,
22 its development is as follow:
24 * As soon a new kernel is released a two weeks windows is open, during
25 this period of time maintainers can submit big diffs to Linus, usually
26 the patched sited in -mm kernels for a few weeks.
27 Preferred way to submit big changes is using GIT
28 (more information about GIT at http://git.or.cz/ and
29 http://www.kernel.org/pub/software/scm/git/docs/tutorial.html).
31 * After two weeks a -rc1 kernel is released,is now possible to
32 push only patches that do not include new functionalities that could
33 affect the stability of the whole kernel. Please note that a whole
34 new driver (or filesystem) might be accepted
35 after -rc1 because there is no risk of causing regressions with
36 such a change
38 * A new -rc is released whenever Linus deems the current git
39 (the kernel's source management) tree to be in a reasonably sane state
40 adequate for testing. The goal is to release a new -rc kernel every week.
42 * Process continues until the kernel is considered "ready", the
43 process should last around 6 weeks ( 6 kernels per year should be
44 released) an usually includes 4/5 rc releases.
46 There a numbers of tools used by the community to measure the quality and the
47 performance of a kernel.
48 A couple of examples are:
50 * kernel-perf.sourceforge.net
51 Copy and paste from the project description:
52 "We are a group of dedicated Linux kernel engineers taking on the challenge
53 of testing the Linux kernel. In order to track performance, we are running
54 a large set of benchmarks covering core components of the Linux kernel
55 (virtual memory management, I/O subsystem, process scheduler, file system,
56 network, device driver, etc). Benchmarks are run on a variety of platforms
57 every week, testing the latest snapshot of Linus' git development tree.
58 Comprehensive performance data from our tests will be hosted here for
59 easy access."
61 * bugzilla.kernel.org
62 It's the official bugzilla instance used as an online kernel bug tracking.
63 Users are invited to report all the bugs they hit using this tool.
65 But it's worth to mention what Andrew Morton wrote on lkml:
66 "Nobody knows when a kernel will be released, because it's released
67 according to perceived bug status, not according to a preconceived
68 timeline."
71 2.6.x.y kernels, a.k.a -stable
72 ------------------------------
74 Kernels with 4 digit versions are -stable kernels. They contain small(ish)
75 critical fixes for security problems or significant regressions discovered
76 in a given 2.6.x kernel.
78 This is the recommended branch for users who want the most recent stable
79 kernel and are not interested in helping test development/experimental
80 versions.
82 If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is
83 the current stable kernel.
85 2.6.x.y are maintained by the "stable" team (stable at kernel dot
86 org), are released almost every week.
88 Rules on what kind of patches are accepted, and what ones are not, into
89 the "-stable" tree:
91 * It must be obviously correct and tested.
92 * It can not bigger than 100 lines, with context.
93 * It must fix only one thing.
94 * It must fix a real bug that bothers people (not a, "This could be a
95 problem..." type thing.)
96 * It must fix a problem that causes a build error (but not for things
97 marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
98 security issue, or some "oh, that's not good" issue. In short,
99 something critical.
100 * No "theoretical race condition" issues, unless an explanation of how
101 the race can be exploited.
102 * It can not contain any "trivial" fixes in it (spelling changes,
103 whitespace cleanups, etc.)
104 * It must be accepted by the relevant subsystem maintainer.
105 * It must follow Documentation/SubmittingPatches rules.
107 Procedure for submitting patches to the -stable tree:
109 * Send the patch, after verifying that it follows the above rules, to
110 stable@kernel.org.
111 * The sender will receive an ack when the patch has been accepted into
112 the queue, or a nak if the patch is rejected. This response might
113 take a few days, according to the developer's schedules.
114 * If accepted, the patch will be added to the -stable queue, for review
115 by other developers.
116 * Security patches should not be sent to this alias, but instead to the
117 documented security@kernel.org.
119 Review cycle:
121 * When the -stable maintainers decide for a review cycle, the patches
122 will be sent to the review committee, and the maintainer of the
123 affected area of the patch (unless the submitter is the maintainer of
124 the area) and CC: to the linux-kernel mailing list.
125 * The review committee has 48 hours in which to ack or nak the patch.
126 * If the patch is rejected by a member of the committee, or linux-kernel
127 members object to the patch by bringing up issues that the maintainer
128 and members did not realize, the patch will be dropped from the
129 queue.
130 * At the end of the review cycle, the acked patches will be added to
131 the latest -stable release, and a new -stable release will happen.
132 * Security patches will be accepted into the -stable tree directly from
133 the security kernel team, and not go through the normal review cycle.
134 Contact the kernel security team for more details on this procedure.
136 Review committee:
137 This will be made up of a number of kernel developers who have
138 volunteered for this task, and a few that haven't.
141 The -mm kernels
142 ---------------
144 These are experimental kernels released by Andrew Morton.
146 The -mm tree serves as a sort of proving ground for new features and other
147 experimental patches.
148 Once a patch has proved its worth in -mm for a while Andrew pushes it on to
149 Linus for inclusion in mainline.
151 Although it's encouraged that patches flow to Linus via the -mm tree, this
152 is not always enforced.
153 Subsystem maintainers (or individuals) sometimes push their patches directly
154 to Linus, even though (or after) they have been merged and tested in -mm (or
155 sometimes even without prior testing in -mm).
157 This branch is in constant flux and contains many experimental features, a
158 lot of debugging patches not appropriate for mainline etc and is the most
159 experimental of the branches described in this document.
161 These kernels are not appropriate for use on systems that are supposed to be
162 stable and they are more risky to run than any of the other branches (make
163 sure you have up-to-date backups - that goes for any experimental kernel but
164 even more so for -mm kernels).
166 These kernels in addition to all the other experimental patches they contain
167 usually also contain any changes in the mainline -git kernels available at
168 the time of release.
170 The -mm kernels are not released on a fixed schedule, but usually a few -mm
171 kernels are released in between each -rc kernel (1 to 3 is common).
173 The -git kernels
174 ----------------
176 These are daily snapshots of Linus' kernel tree (managed in a git
177 repository, hence the name).
179 These patches are usually released daily and represent the current state of
180 Linus' tree. They are more experimental than -rc kernels since they are
181 generated automatically without even a cursory glance to see if they are
182 sane.
184 I hope you enjoy reading this article and I really deserve
185 special thanks to Tony Luck and Jesper Juhl for their suggestions!!
187 Part of this article is from the document written by Jesper Juhl,
188 you can find it here:
189 http://sosdg.org/~coywolf/lxr/source/Documentation/applying-patches.txt