Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^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.