^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. _development_process:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) How the development process works
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) Linux kernel development in the early 1990's was a pretty loose affair,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) with relatively small numbers of users and developers involved. With a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) user base in the millions and with some 2,000 developers involved over the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) course of one year, the kernel has since had to evolve a number of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) processes to keep development happening smoothly. A solid understanding of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) how the process works is required in order to be an effective part of it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) The big picture
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) The kernel developers use a loosely time-based release process, with a new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) major kernel release happening every two or three months. The recent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) release history looks like this:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) ====== =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) 5.0 March 3, 2019
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) 5.1 May 5, 2019
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) 5.2 July 7, 2019
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 5.3 September 15, 2019
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 5.4 November 24, 2019
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) 5.5 January 6, 2020
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) ====== =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Every 5.x release is a major kernel release with new features, internal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) API changes, and more. A typical release can contain about 13,000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) changesets with changes to several hundred thousand lines of code. 5.x is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) the leading edge of Linux kernel development; the kernel uses a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) rolling development model which is continually integrating major changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) A relatively straightforward discipline is followed with regard to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) merging of patches for each release. At the beginning of each development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) cycle, the "merge window" is said to be open. At that time, code which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) deemed to be sufficiently stable (and which is accepted by the development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) community) is merged into the mainline kernel. The bulk of changes for a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) new development cycle (and all of the major changes) will be merged during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) this time, at a rate approaching 1,000 changes ("patches," or "changesets")
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) per day.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) (As an aside, it is worth noting that the changes integrated during the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) merge window do not come out of thin air; they have been collected, tested,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) and staged ahead of time. How that process works will be described in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) detail later on).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) The merge window lasts for approximately two weeks. At the end of this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) time, Linus Torvalds will declare that the window is closed and release the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) first of the "rc" kernels. For the kernel which is destined to be 5.6,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) for example, the release which happens at the end of the merge window will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) be called 5.6-rc1. The -rc1 release is the signal that the time to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) merge new features has passed, and that the time to stabilize the next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) kernel has begun.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Over the next six to ten weeks, only patches which fix problems should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) submitted to the mainline. On occasion a more significant change will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) allowed, but such occasions are rare; developers who try to merge new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) features outside of the merge window tend to get an unfriendly reception.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) As a general rule, if you miss the merge window for a given feature, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) best thing to do is to wait for the next development cycle. (An occasional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) exception is made for drivers for previously-unsupported hardware; if they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) touch no in-tree code, they cannot cause regressions and should be safe to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) add at any time).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) As fixes make their way into the mainline, the patch rate will slow over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) time. Linus releases new -rc kernels about once a week; a normal series
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) will get up to somewhere between -rc6 and -rc9 before the kernel is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) considered to be sufficiently stable and the final release is made.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) At that point the whole process starts over again.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) As an example, here is how the 5.4 development cycle went (all dates in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) 2019):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ============== ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) September 15 5.3 stable release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) September 30 5.4-rc1, merge window closes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) October 6 5.4-rc2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) October 13 5.4-rc3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) October 20 5.4-rc4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) October 27 5.4-rc5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) November 3 5.4-rc6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) November 10 5.4-rc7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) November 17 5.4-rc8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) November 24 5.4 stable release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) ============== ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) How do the developers decide when to close the development cycle and create
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) the stable release? The most significant metric used is the list of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) regressions from previous releases. No bugs are welcome, but those which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) break systems which worked in the past are considered to be especially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) serious. For this reason, patches which cause regressions are looked upon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) unfavorably and are quite likely to be reverted during the stabilization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) period.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) The developers' goal is to fix all known regressions before the stable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) release is made. In the real world, this kind of perfection is hard to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) achieve; there are just too many variables in a project of this size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) There comes a point where delaying the final release just makes the problem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) worse; the pile of changes waiting for the next merge window will grow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) larger, creating even more regressions the next time around. So most 5.x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) kernels go out with a handful of known regressions though, hopefully, none
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) of them are serious.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) Once a stable release is made, its ongoing maintenance is passed off to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) "stable team," currently Greg Kroah-Hartman. The stable team will release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) occasional updates to the stable release using the 5.x.y numbering scheme.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) To be considered for an update release, a patch must (1) fix a significant
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) bug, and (2) already be merged into the mainline for the next development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) kernel. Kernels will typically receive stable updates for a little more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) than one development cycle past their initial release. So, for example, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) 5.2 kernel's history looked like this (all dates in 2019):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ============== ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) July 7 5.2 stable release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) July 14 5.2.1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) July 21 5.2.2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) July 26 5.2.3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) July 28 5.2.4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) July 31 5.2.5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) ... ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) October 11 5.2.21
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) ============== ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) 5.2.21 was the final stable update of the 5.2 release.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) Some kernels are designated "long term" kernels; they will receive support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) for a longer period. As of this writing, the current long term kernels
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) and their maintainers are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) ====== ================================ =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 3.16 Ben Hutchings (very long-term kernel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) 4.4 Greg Kroah-Hartman & Sasha Levin (very long-term kernel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) 4.9 Greg Kroah-Hartman & Sasha Levin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) 4.14 Greg Kroah-Hartman & Sasha Levin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) 4.19 Greg Kroah-Hartman & Sasha Levin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) 5.4 Greg Kroah-Hartman & Sasha Levin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) ====== ================================ =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) The selection of a kernel for long-term support is purely a matter of a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) maintainer having the need and the time to maintain that release. There
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) are no known plans for long-term support for any specific upcoming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) release.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) The lifecycle of a patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) ------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) Patches do not go directly from the developer's keyboard into the mainline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) kernel. There is, instead, a somewhat involved (if somewhat informal)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) process designed to ensure that each patch is reviewed for quality and that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) each patch implements a change which is desirable to have in the mainline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) This process can happen quickly for minor fixes, or, in the case of large
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) and controversial changes, go on for years. Much developer frustration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) comes from a lack of understanding of this process or from attempts to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) circumvent it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) In the hopes of reducing that frustration, this document will describe how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) a patch gets into the kernel. What follows below is an introduction which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) describes the process in a somewhat idealized way. A much more detailed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) treatment will come in later sections.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) The stages that a patch goes through are, generally:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) - Design. This is where the real requirements for the patch - and the way
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) those requirements will be met - are laid out. Design work is often
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) done without involving the community, but it is better to do this work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) in the open if at all possible; it can save a lot of time redesigning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) things later.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) - Early review. Patches are posted to the relevant mailing list, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) developers on that list reply with any comments they may have. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) process should turn up any major problems with a patch if all goes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) - Wider review. When the patch is getting close to ready for mainline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) inclusion, it should be accepted by a relevant subsystem maintainer -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) though this acceptance is not a guarantee that the patch will make it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) all the way to the mainline. The patch will show up in the maintainer's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) subsystem tree and into the -next trees (described below). When the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) process works, this step leads to more extensive review of the patch and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) the discovery of any problems resulting from the integration of this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) patch with work being done by others.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) - Please note that most maintainers also have day jobs, so merging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) your patch may not be their highest priority. If your patch is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) getting feedback about changes that are needed, you should either
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) make those changes or justify why they should not be made. If your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) patch has no review complaints but is not being merged by its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) appropriate subsystem or driver maintainer, you should be persistent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) in updating the patch to the current kernel so that it applies cleanly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) and keep sending it for review and merging.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) - Merging into the mainline. Eventually, a successful patch will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) merged into the mainline repository managed by Linus Torvalds. More
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) comments and/or problems may surface at this time; it is important that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) the developer be responsive to these and fix any issues which arise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) - Stable release. The number of users potentially affected by the patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) is now large, so, once again, new problems may arise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) - Long-term maintenance. While it is certainly possible for a developer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) to forget about code after merging it, that sort of behavior tends to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) leave a poor impression in the development community. Merging code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) eliminates some of the maintenance burden, in that others will fix
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) problems caused by API changes. But the original developer should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) continue to take responsibility for the code if it is to remain useful
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) in the longer term.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) One of the largest mistakes made by kernel developers (or their employers)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) is to try to cut the process down to a single "merging into the mainline"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) step. This approach invariably leads to frustration for everybody
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) involved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) How patches get into the Kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) There is exactly one person who can merge patches into the mainline kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) repository: Linus Torvalds. But, for example, of the over 9,500 patches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) which went into the 2.6.38 kernel, only 112 (around 1.3%) were directly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) chosen by Linus himself. The kernel project has long since grown to a size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) where no single developer could possibly inspect and select every patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) unassisted. The way the kernel developers have addressed this growth is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) through the use of a lieutenant system built around a chain of trust.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) The kernel code base is logically broken down into a set of subsystems:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) networking, specific architecture support, memory management, video
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) devices, etc. Most subsystems have a designated maintainer, a developer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) who has overall responsibility for the code within that subsystem. These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) subsystem maintainers are the gatekeepers (in a loose way) for the portion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) of the kernel they manage; they are the ones who will (usually) accept a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) patch for inclusion into the mainline kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) Subsystem maintainers each manage their own version of the kernel source
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) tree, usually (but certainly not always) using the git source management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) tool. Tools like git (and related tools like quilt or mercurial) allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) maintainers to track a list of patches, including authorship information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) and other metadata. At any given time, the maintainer can identify which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) patches in his or her repository are not found in the mainline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) When the merge window opens, top-level maintainers will ask Linus to "pull"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) the patches they have selected for merging from their repositories. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) Linus agrees, the stream of patches will flow up into his repository,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) becoming part of the mainline kernel. The amount of attention that Linus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) pays to specific patches received in a pull operation varies. It is clear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) that, sometimes, he looks quite closely. But, as a general rule, Linus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) trusts the subsystem maintainers to not send bad patches upstream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) Subsystem maintainers, in turn, can pull patches from other maintainers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) For example, the networking tree is built from patches which accumulated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) first in trees dedicated to network device drivers, wireless networking,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) etc. This chain of repositories can be arbitrarily long, though it rarely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) exceeds two or three links. Since each maintainer in the chain trusts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) those managing lower-level trees, this process is known as the "chain of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) trust."
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) Clearly, in a system like this, getting patches into the kernel depends on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) finding the right maintainer. Sending patches directly to Linus is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) normally the right way to go.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) Next trees
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) The chain of subsystem trees guides the flow of patches into the kernel,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) but it also raises an interesting question: what if somebody wants to look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) at all of the patches which are being prepared for the next merge window?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) Developers will be interested in what other changes are pending to see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) whether there are any conflicts to worry about; a patch which changes a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) core kernel function prototype, for example, will conflict with any other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) patches which use the older form of that function. Reviewers and testers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) want access to the changes in their integrated form before all of those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) changes land in the mainline kernel. One could pull changes from all of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) the interesting subsystem trees, but that would be a big and error-prone
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) job.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) The answer comes in the form of -next trees, where subsystem trees are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) collected for testing and review. The older of these trees, maintained by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) Andrew Morton, is called "-mm" (for memory management, which is how it got
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) started). The -mm tree integrates patches from a long list of subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) trees; it also has some patches aimed at helping with debugging.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) Beyond that, -mm contains a significant collection of patches which have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) been selected by Andrew directly. These patches may have been posted on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) mailing list, or they may apply to a part of the kernel for which there is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) no designated subsystem tree. As a result, -mm operates as a sort of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) subsystem tree of last resort; if there is no other obvious path for a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) patch into the mainline, it is likely to end up in -mm. Miscellaneous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) patches which accumulate in -mm will eventually either be forwarded on to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) an appropriate subsystem tree or be sent directly to Linus. In a typical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) development cycle, approximately 5-10% of the patches going into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) mainline get there via -mm.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) The current -mm patch is available in the "mmotm" (-mm of the moment)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) directory at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) https://www.ozlabs.org/~akpm/mmotm/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) Use of the MMOTM tree is likely to be a frustrating experience, though;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) there is a definite chance that it will not even compile.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) The primary tree for next-cycle patch merging is linux-next, maintained by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) the mainline is expected to look like after the next merge window closes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) Linux-next trees are announced on the linux-kernel and linux-next mailing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) lists when they are assembled; they can be downloaded from:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) https://www.kernel.org/pub/linux/kernel/next/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) Linux-next has become an integral part of the kernel development process;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) all patches merged during a given merge window should really have found
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) their way into linux-next some time before the merge window opens.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) Staging trees
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) The kernel source tree contains the drivers/staging/ directory, where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) many sub-directories for drivers or filesystems that are on their way to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) being added to the kernel tree live. They remain in drivers/staging while
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) they still need more work; once complete, they can be moved into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) kernel proper. This is a way to keep track of drivers that aren't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) up to Linux kernel coding or quality standards, but people may want to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) them and track development.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) Greg Kroah-Hartman currently maintains the staging tree. Drivers that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) still need work are sent to him, with each driver having its own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) subdirectory in drivers/staging/. Along with the driver source files, a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) TODO file should be present in the directory as well. The TODO file lists
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) the pending work that the driver needs for acceptance into the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) proper, as well as a list of people that should be Cc'd for any patches to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) the driver. Current rules require that drivers contributed to staging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) must, at a minimum, compile properly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) Staging can be a relatively easy way to get new drivers into the mainline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) where, with luck, they will come to the attention of other developers and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) improve quickly. Entry into staging is not the end of the story, though;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) code in staging which is not seeing regular progress will eventually be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) removed. Distributors also tend to be relatively reluctant to enable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) staging drivers. So staging is, at best, a stop on the way toward becoming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) a proper mainline driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) Tools
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) -----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) As can be seen from the above text, the kernel development process depends
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) heavily on the ability to herd collections of patches in various
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) directions. The whole thing would not work anywhere near as well as it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) does without suitably powerful tools. Tutorials on how to use these tools
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) are well beyond the scope of this document, but there is space for a few
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) pointers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) By far the dominant source code management system used by the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) community is git. Git is one of a number of distributed version control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) systems being developed in the free software community. It is well tuned
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) for kernel development, in that it performs quite well when dealing with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) large repositories and large numbers of patches. It also has a reputation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) for being difficult to learn and use, though it has gotten better over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) time. Some sort of familiarity with git is almost a requirement for kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) developers; even if they do not use it for their own work, they'll need git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) to keep up with what other developers (and the mainline) are doing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) Git is now packaged by almost all Linux distributions. There is a home
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) page at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) https://git-scm.com/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) That page has pointers to documentation and tutorials.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) Among the kernel developers who do not use git, the most popular choice is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) almost certainly Mercurial:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) https://www.selenic.com/mercurial/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) Mercurial shares many features with git, but it provides an interface which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) many find easier to use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) The other tool worth knowing about is Quilt:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) https://savannah.nongnu.org/projects/quilt/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) Quilt is a patch management system, rather than a source code management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) system. It does not track history over time; it is, instead, oriented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) toward tracking a specific set of changes against an evolving code base.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) Some major subsystem maintainers use quilt to manage patches intended to go
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) upstream. For the management of certain kinds of trees (-mm, for example),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) quilt is the best tool for the job.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) Mailing lists
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) A great deal of Linux kernel development work is done by way of mailing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) lists. It is hard to be a fully-functioning member of the community
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) without joining at least one list somewhere. But Linux mailing lists also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) represent a potential hazard to developers, who risk getting buried under a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) load of electronic mail, running afoul of the conventions used on the Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) lists, or both.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) Most kernel mailing lists are run on vger.kernel.org; the master list can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) be found at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) http://vger.kernel.org/vger-lists.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) There are lists hosted elsewhere, though; a number of them are at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) redhat.com/mailman/listinfo.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) The core mailing list for kernel development is, of course, linux-kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) This list is an intimidating place to be; volume can reach 500 messages per
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) day, the amount of noise is high, the conversation can be severely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) technical, and participants are not always concerned with showing a high
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) degree of politeness. But there is no other place where the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) development community comes together as a whole; developers who avoid this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) list will miss important information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) There are a few hints which can help with linux-kernel survival:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) - Have the list delivered to a separate folder, rather than your main
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) mailbox. One must be able to ignore the stream for sustained periods of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) - Do not try to follow every conversation - nobody else does. It is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) important to filter on both the topic of interest (though note that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) long-running conversations can drift away from the original subject
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) without changing the email subject line) and the people who are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) participating.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) - Do not feed the trolls. If somebody is trying to stir up an angry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) response, ignore them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) - When responding to linux-kernel email (or that on other lists) preserve
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) the Cc: header for all involved. In the absence of a strong reason (such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) as an explicit request), you should never remove recipients. Always make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) sure that the person you are responding to is in the Cc: list. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) convention also makes it unnecessary to explicitly ask to be copied on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) replies to your postings.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) - Search the list archives (and the net as a whole) before asking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) questions. Some developers can get impatient with people who clearly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) have not done their homework.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) - Avoid top-posting (the practice of putting your answer above the quoted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) text you are responding to). It makes your response harder to read and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) makes a poor impression.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) - Ask on the correct mailing list. Linux-kernel may be the general meeting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) point, but it is not the best place to find developers from all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) The last point - finding the correct mailing list - is a common place for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) beginning developers to go wrong. Somebody who asks a networking-related
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) question on linux-kernel will almost certainly receive a polite suggestion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) to ask on the netdev list instead, as that is the list frequented by most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) networking developers. Other lists exist for the SCSI, video4linux, IDE,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) filesystem, etc. subsystems. The best place to look for mailing lists is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) in the MAINTAINERS file packaged with the kernel source.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) Getting started with Kernel development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) Questions about how to get started with the kernel development process are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) common - from both individuals and companies. Equally common are missteps
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) which make the beginning of the relationship harder than it has to be.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) Companies often look to hire well-known developers to get a development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) group started. This can, in fact, be an effective technique. But it also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) tends to be expensive and does not do much to grow the pool of experienced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) kernel developers. It is possible to bring in-house developers up to speed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) on Linux kernel development, given the investment of a bit of time. Taking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) this time can endow an employer with a group of developers who understand
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) the kernel and the company both, and who can help to train others as well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) Over the medium term, this is often the more profitable approach.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) Individual developers are often, understandably, at a loss for a place to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) start. Beginning with a large project can be intimidating; one often wants
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) to test the waters with something smaller first. This is the point where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) some developers jump into the creation of patches fixing spelling errors or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) minor coding style issues. Unfortunately, such patches create a level of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) noise which is distracting for the development community as a whole, so,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) increasingly, they are looked down upon. New developers wishing to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) introduce themselves to the community will not get the sort of reception
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) they wish for by these means.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) Andrew Morton gives this advice for aspiring kernel developers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) The #1 project for all kernel beginners should surely be "make sure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) that the kernel runs perfectly at all times on all machines which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) you can lay your hands on". Usually the way to do this is to work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) with others on getting things fixed up (this can require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) persistence!) but that's fine - it's a part of kernel development.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) (https://lwn.net/Articles/283982/).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) In the absence of obvious problems to fix, developers are advised to look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) at the current lists of regressions and open bugs in general. There is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) never any shortage of issues in need of fixing; by addressing these issues,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) developers will gain experience with the process while, at the same time,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) building respect with the rest of the development community.