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
86 linux-api@vger.kernel.org.
88 Here is a list of files that are in the kernel source tree that are
91 :ref:`Documentation/admin-guide/README.rst <readme>`
92 This file gives a short background on the Linux kernel and describes
93 what is necessary to do to configure and build the kernel. People
94 who are new to the kernel should start here.
98 packages that are necessary to build and run the kernel
101 :ref:`Documentation/process/coding-style.rst <codingstyle>`
102 This describes the Linux kernel coding style, and some of the
104 guidelines in this document. Most maintainers will only accept
106 review code if it is in the proper style.
108 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
109 This file describes in explicit detail how to successfully create
112 - Email contents
113 - Email format
114 - Who to send it to
125 "Linux kernel patch submission format"
126 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
128 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
130 not have a stable API within the kernel, including things like:
132 - Subsystem shim-layers (for compatibility?)
133 - Driver portability between Operating Systems.
134 - Mitigating rapid change within the kernel source tree (or
141 :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
142 If you feel you have found a security problem in the Linux kernel,
143 please follow the steps in this document to help notify the kernel
146 :ref:`Documentation/process/management-style.rst <managementstyle>`
147 This document describes how Linux kernel maintainers operate and the
149 for anyone new to kernel development (or anyone simply curious about
151 about the unique behavior of kernel maintainers.
153 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
154 This file describes the rules on how the stable kernel releases
158 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
159 A list of external documentation that pertains to kernel
161 are looking for within the in-kernel documentation.
163 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
165 apply it to the different development branches of the kernel.
167 The kernel also has a large number of documents that can be
170 full description of the in-kernel API, and rules on how to handle
178 respectively from the main kernel source directory.
186 Becoming A Kernel Developer
187 ---------------------------
189 If you do not know anything about Linux kernel development, you should
195 of basic kernel development question (make sure to search the archives
196 first, before asking something that has already been answered in the
197 past.) It also has an IRC channel that you can use to ask questions in
198 real-time, and a lot of helpful documentation that is useful for
199 learning about Linux kernel development.
202 and current projects (both in-tree and out-of-tree). It also describes
203 some basic logistical information, like how to compile a kernel and
207 some task to start doing to join into the kernel development community,
208 go to the Linux Kernel Janitor's project:
213 problems that need to be cleaned up and fixed within the Linux kernel
214 source tree. Working with the developers in charge of this project, you
215 will learn the basics of getting your patch into the Linux kernel tree,
216 and possibly be pointed in the direction of what to go work on next, if
219 Before making any actual modifications to the Linux kernel code, it is
220 imperative to understand how the code in question works. For this
224 Cross-Reference project, which is able to present source code in a
225 self-referential, indexed webpage format. An excellent up-to-date
226 repository of the kernel code may be found at:
232 -----------------------
234 Linux kernel development process currently consists of a few different
235 main kernel "branches" and lots of different subsystem-specific kernel
238 - Linus's mainline tree
239 - Various stable trees with multiple major numbers
240 - Subsystem-specific trees
241 - linux-next integration testing tree
247 https://kernel.org or in the repo. Its development process is as follows:
249 - As soon as a new kernel is released a two week window is open,
251 Linus, usually the patches that have already been included in the
252 linux-next for a few weeks. The preferred way to submit big changes
253 is using git (the kernel's source management tool, more information
254 can be found at https://git-scm.com/) but plain patches are also just
256 - After two weeks a -rc1 kernel is released and the focus is on making the
257 new kernel as rock solid as possible. Most of the patches at this point
261 after -rc1 because there is no risk of causing regressions with such a
262 change as long as the change is self-contained and does not affect areas
264 patches to Linus after -rc1 is released, but the patches need to also be
266 - A new -rc is released whenever Linus deems the current git tree to
267 be in a reasonably sane state adequate for testing. The goal is to
268 release a new -rc kernel every week.
269 - Process continues until the kernel is considered "ready", the
272 It is worth mentioning what Andrew Morton wrote on the linux-kernel
273 mailing list about kernel releases:
275 *"Nobody knows when a kernel will be released, because it's
282 Kernels with 3-part versions are -stable kernels. They contain
284 regressions discovered in a given major mainline release. Each release
285 in a major stable series increments the third part of the version
289 kernel and are not interested in helping test development/experimental
292 Stable trees are maintained by the "stable" team <stable@vger.kernel.org>, and
295 security-related problem, instead, can cause a release to happen almost
298 The file :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
299 in the kernel tree documents what kinds of changes are acceptable for
300 the -stable tree, and how the release process works.
302 Subsystem-specific trees
305 The maintainers of the various kernel subsystems --- and also many
306 kernel subsystem developers --- expose their current state of
307 development in source repositories. That way, others can see what is
308 happening in the different areas of the kernel. In areas where
310 onto such a subsystem kernel tree so that conflicts between the
314 in use, or patch queues being published as quilt series. Addresses of
315 these subsystem repositories are listed in the MAINTAINERS file. Many
316 of them can be browsed at https://git.kernel.org/.
320 respective section below). For several kernel subsystems, this review
325 https://patchwork.kernel.org/.
327 linux-next integration testing tree
331 they need to be integration-tested. For this purpose, a special
335 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
337 This way, the linux-next gives a summary outlook onto what will be
338 expected to go into the mainline kernel at the next merge period.
339 Adventurous testers are very welcome to runtime-test the linux-next.
343 -------------
345 The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
346 source directory describes how to report a possible kernel bug, and details
347 what kind of information is needed by the kernel developers to help track
352 --------------------
355 bugs reported by other people. Not only you will help to make the kernel
361 To work on already reported bug reports, find a subsystem you are interested in.
365 https://bugzilla.kernel.org for bug reports; only a handful of kernel subsystems
367 kernel get filed there.
371 -------------
373 As some of the above documents describe, the majority of the core kernel
374 developers participate on the Linux Kernel Mailing list. Details on how
377 http://vger.kernel.org/vger-lists.html#linux-kernel
379 There are archives of the mailing list on the web in many different
382 https://lore.kernel.org/lkml/
386 already discussed in detail are only recorded at the mailing list
389 Most of the individual kernel subsystems also have their own separate
394 Many of the lists are hosted on kernel.org. Information on them can be
397 http://vger.kernel.org/vger-lists.html
409 to tune that by adding fancy mail-headers, people will not like it.
417 as stated in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
418 Kernel developers don't want to deal with
430 --------------------------
432 The goal of the kernel community is to provide the best possible kernel
437 - criticism
438 - comments
439 - requests for change
440 - requests for justification
441 - silence
443 Remember, this is part of getting your patch into the kernel. You have
448 again, sometimes things get lost in the huge volume.
452 - expect your patch to be accepted without question
453 - become defensive
454 - ignore comments
455 - resubmit the patch without making any of the requested changes
457 In a community that is looking for the best technical solution possible,
460 the kernel. Or at least be willing to prove your idea is worth it.
471 Differences between the kernel community and corporate structures
472 -----------------------------------------------------------------
474 The kernel community works differently than most traditional corporate
480 - "This solves multiple problems."
481 - "This deletes 2000 lines of code."
482 - "Here is a patch that explains what I am trying to describe."
483 - "I tested it on 5 different architectures..."
484 - "Here is a series of small patches that..."
485 - "This increases performance on typical machines..."
489 - "We did it this way in AIX/ptx/Solaris, so therefore it must be
491 - "I've being doing this for 20 years, so..."
492 - "This is required for my company to make money"
493 - "This is for our Enterprise product line."
494 - "Here is my 1000 page design document that describes my idea"
495 - "I've been working on this for 6 months..."
496 - "Here's a 5000 line patch that..."
497 - "I rewrote all of the current mess, and here it is..."
498 - "I have a deadline, and this patch needs to be applied now."
500 Another way the kernel community is different than most traditional
504 The Linux kernel work environment is accepting of women and minorities
508 Most women who have worked in the Linux kernel and have expressed an
512 comfortable with English. A good grasp of the language can be needed in
514 recommended that you check your emails to make sure they make sense in
519 ---------------------
521 The Linux kernel community does not gladly accept large chunks of code
525 should also be introduced very early in the development process, so that
547 and simplify (or simply re-order) patches before submitting them.
549 Here is an analogy from kernel developer Al Viro:
558 *The same is true of kernel development. The maintainers and
565 unfinished work. Therefore it is good to get early in the process to
566 get feedback to improve your work, but also keep your changes in small
575 -------------------
583 --------------------
585 When sending in your patches, pay special attention to what you say in
586 the text in your email. This information will become the ChangeLog
590 - why the change is necessary
591 - the overall design approach in the patch
592 - implementation details
593 - testing results
611 ----------
626 Maintainer: Greg Kroah-Hartman <greg@kroah.com>