Lines Matching +full:in +full:- +full:kernel
3 HOWTO do Linux kernel development
6 This is the be-all, end-all document on this topic. It contains
7 instructions on how to become a Linux kernel developer and how to learn
8 to work with the Linux kernel development community. It tries to not
9 contain anything related to the technical aspects of kernel programming,
10 but will help point you in the right direction for that.
12 If anything in this document becomes out of date, please send in patches
18 ------------
20 So, you want to learn how to become a Linux kernel developer? Or you
27 The kernel is written mostly in C, with some architecture-dependent
28 parts written in assembly. A good understanding of C is required for
29 kernel development. Assembly (any architecture) is not required unless
30 you plan to do low-level development for that architecture. Though they
34 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
35 - "Practical C Programming" by Steve Oualline [O'Reilly]
36 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
38 The kernel is written using GNU C and the GNU toolchain. While it
40 not featured in the standard. The kernel is a freestanding C
44 difficult to understand the assumptions the kernel has on the toolchain
60 ------------
62 The Linux kernel source code is released under the GPL. Please see the file
63 COPYING in the main directory of the source tree. The Linux kernel licensing
64 rules and how to use `SPDX <https://spdx.org/>`_ identifiers in source code are
65 described in :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
67 not ask on the Linux kernel mailing list. The people on the mailing lists are
72 https://www.gnu.org/licenses/gpl-faq.html
76 -------------
78 The Linux kernel source tree has a large range of documents that are
79 invaluable for learning how to interact with the kernel community. When
80 new features are added to the kernel, it is recommended that new
82 When a kernel change causes the interface that the kernel exposes to
85 maintainer at alx@kernel.org, and CC the list linux-api@vger.kernel.org.
87 Here is a list of files that are in the kernel source tree that are
90 :ref:`Documentation/admin-guide/README.rst <readme>`
91 This file gives a short background on the Linux kernel and describes
92 what is necessary to do to configure and build the kernel. People
93 who are new to the kernel should start here.
97 packages that are necessary to build and run the kernel
100 :ref:`Documentation/process/coding-style.rst <codingstyle>`
101 This describes the Linux kernel coding style, and some of the
103 guidelines in this document. Most maintainers will only accept
105 review code if it is in the proper style.
107 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
108 This file describes in explicit detail how to successfully create
111 - Email contents
112 - Email format
113 - Who to send it to
124 "Linux kernel patch submission format"
125 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
127 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
129 not have a stable API within the kernel, including things like:
131 - Subsystem shim-layers (for compatibility?)
132 - Driver portability between Operating Systems.
133 - Mitigating rapid change within the kernel source tree (or
140 :ref:`Documentation/process/security-bugs.rst <securitybugs>`
141 If you feel you have found a security problem in the Linux kernel,
142 please follow the steps in this document to help notify the kernel
145 :ref:`Documentation/process/management-style.rst <managementstyle>`
146 This document describes how Linux kernel maintainers operate and the
148 for anyone new to kernel development (or anyone simply curious about
150 about the unique behavior of kernel maintainers.
152 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
153 This file describes the rules on how the stable kernel releases
157 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
158 A list of external documentation that pertains to kernel
160 are looking for within the in-kernel documentation.
162 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
164 apply it to the different development branches of the kernel.
166 The kernel also has a large number of documents that can be
169 full description of the in-kernel API, and rules on how to handle
177 respectively from the main kernel source directory.
185 Becoming A Kernel Developer
186 ---------------------------
188 If you do not know anything about Linux kernel development, you should
194 of basic kernel development question (make sure to search the archives
195 first, before asking something that has already been answered in the
196 past.) It also has an IRC channel that you can use to ask questions in
197 real-time, and a lot of helpful documentation that is useful for
198 learning about Linux kernel development.
201 and current projects (both in-tree and out-of-tree). It also describes
202 some basic logistical information, like how to compile a kernel and
206 some task to start doing to join into the kernel development community,
207 go to the Linux Kernel Janitor's project:
212 problems that need to be cleaned up and fixed within the Linux kernel
213 source tree. Working with the developers in charge of this project, you
214 will learn the basics of getting your patch into the Linux kernel tree,
215 and possibly be pointed in the direction of what to go work on next, if
218 Before making any actual modifications to the Linux kernel code, it is
219 imperative to understand how the code in question works. For this
223 Cross-Reference project, which is able to present source code in a
224 self-referential, indexed webpage format. An excellent up-to-date
225 repository of the kernel code may be found at:
231 -----------------------
233 Linux kernel development process currently consists of a few different
234 main kernel "branches" and lots of different subsystem-specific kernel
237 - Linus's mainline tree
238 - Various stable trees with multiple major numbers
239 - Subsystem-specific trees
240 - linux-next integration testing tree
246 https://kernel.org or in the repo. Its development process is as follows:
248 - As soon as a new kernel is released a two week window is open,
250 Linus, usually the patches that have already been included in the
251 linux-next for a few weeks. The preferred way to submit big changes
252 is using git (the kernel's source management tool, more information
253 can be found at https://git-scm.com/) but plain patches are also just
255 - After two weeks a -rc1 kernel is released and the focus is on making the
256 new kernel as rock solid as possible. Most of the patches at this point
260 after -rc1 because there is no risk of causing regressions with such a
261 change as long as the change is self-contained and does not affect areas
263 patches to Linus after -rc1 is released, but the patches need to also be
265 - A new -rc is released whenever Linus deems the current git tree to
266 be in a reasonably sane state adequate for testing. The goal is to
267 release a new -rc kernel every week.
268 - Process continues until the kernel is considered "ready", the
271 It is worth mentioning what Andrew Morton wrote on the linux-kernel
272 mailing list about kernel releases:
274 *"Nobody knows when a kernel will be released, because it's
281 Kernels with 3-part versions are -stable kernels. They contain
283 regressions discovered in a given major mainline release. Each release
284 in a major stable series increments the third part of the version
288 kernel and are not interested in helping test development/experimental
291 Stable trees are maintained by the "stable" team <stable@vger.kernel.org>, and
294 security-related problem, instead, can cause a release to happen almost
297 The file :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
298 in the kernel tree documents what kinds of changes are acceptable for
299 the -stable tree, and how the release process works.
301 Subsystem-specific trees
304 The maintainers of the various kernel subsystems --- and also many
305 kernel subsystem developers --- expose their current state of
306 development in source repositories. That way, others can see what is
307 happening in the different areas of the kernel. In areas where
309 onto such a subsystem kernel tree so that conflicts between the
313 in use, or patch queues being published as quilt series. Addresses of
314 these subsystem repositories are listed in the MAINTAINERS file. Many
315 of them can be browsed at https://git.kernel.org/.
319 respective section below). For several kernel subsystems, this review
324 https://patchwork.kernel.org/.
326 linux-next integration testing tree
330 they need to be integration-tested. For this purpose, a special
334 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
336 This way, the linux-next gives a summary outlook onto what will be
337 expected to go into the mainline kernel at the next merge period.
338 Adventurous testers are very welcome to runtime-test the linux-next.
342 -------------
344 The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
345 source directory describes how to report a possible kernel bug, and details
346 what kind of information is needed by the kernel developers to help track
351 --------------------
354 bugs reported by other people. Not only will you help to make the kernel
355 more stable, but you'll also learn to fix real-world problems and you will
360 To work on already reported bug reports, find a subsystem you are interested in.
364 https://bugzilla.kernel.org for bug reports; only a handful of kernel subsystems
366 kernel get filed there.
370 -------------
372 As some of the above documents describe, the majority of the core kernel
373 developers participate on the Linux Kernel Mailing list. Details on how
376 https://subspace.kernel.org/subscribing.html
378 There are archives of the mailing list on the web in many different
381 https://lore.kernel.org/linux-kernel/
385 already discussed in detail are only recorded at the mailing list
388 Most of the individual kernel subsystems also have their own separate
393 Many of the lists are hosted on kernel.org. Information on them can be
396 https://subspace.kernel.org
402 https://subspace.kernel.org/etiquette.html
408 to tune that by adding fancy mail-headers, people will not like it.
416 as stated in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
417 Kernel developers don't want to deal with
429 --------------------------
431 The goal of the kernel community is to provide the best possible kernel
436 - criticism
437 - comments
438 - requests for change
439 - requests for justification
440 - silence
442 Remember, this is part of getting your patch into the kernel. You have
447 again, sometimes things get lost in the huge volume.
451 - expect your patch to be accepted without question
452 - become defensive
453 - ignore comments
454 - resubmit the patch without making any of the requested changes
456 In a community that is looking for the best technical solution possible,
459 the kernel. Or at least be willing to prove your idea is worth it.
470 Differences between the kernel community and corporate structures
471 -----------------------------------------------------------------
473 The kernel community works differently than most traditional corporate
479 - "This solves multiple problems."
480 - "This deletes 2000 lines of code."
481 - "Here is a patch that explains what I am trying to describe."
482 - "I tested it on 5 different architectures..."
483 - "Here is a series of small patches that..."
484 - "This increases performance on typical machines..."
488 - "We did it this way in AIX/ptx/Solaris, so therefore it must be
490 - "I've being doing this for 20 years, so..."
491 - "This is required for my company to make money"
492 - "This is for our Enterprise product line."
493 - "Here is my 1000 page design document that describes my idea"
494 - "I've been working on this for 6 months..."
495 - "Here's a 5000 line patch that..."
496 - "I rewrote all of the current mess, and here it is..."
497 - "I have a deadline, and this patch needs to be applied now."
499 Another way the kernel community is different than most traditional
503 The Linux kernel work environment is accepting of women and minorities
507 Most women who have worked in the Linux kernel and have expressed an
511 comfortable with English. A good grasp of the language can be needed in
513 recommended that you check your emails to make sure they make sense in
518 ---------------------
520 The Linux kernel community does not gladly accept large chunks of code
524 should also be introduced very early in the development process, so that
546 and simplify (or simply re-order) patches before submitting them.
548 Here is an analogy from kernel developer Al Viro:
557 *The same is true of kernel development. The maintainers and
564 unfinished work. Therefore it is good to get early in the process to
565 get feedback to improve your work, but also keep your changes in small
574 -------------------
582 --------------------
584 When sending in your patches, pay special attention to what you say in
585 the text in your email. This information will become the ChangeLog
589 - why the change is necessary
590 - the overall design approach in the patch
591 - implementation details
592 - testing results
610 ----------
625 Maintainer: Greg Kroah-Hartman <greg@kroah.com>