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>` and :ref:`Documentation/pr…
109 These files describe 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 https://bugzilla.kernel.org is where the Linux kernel developers track kernel
346 bugs. Users are encouraged to report all bugs that they find in this
347 tool. For details on how to use the kernel bugzilla, please see:
349 https://bugzilla.kernel.org/page.cgi?id=faq.html
351 The file :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
352 in the main kernel source directory has a good
353 template for how to report a possible kernel bug, and details what kind
354 of information is needed by the kernel developers to help track down the
359 --------------------
362 bugs reported by other people. Not only you will help to make the kernel
368 To work in the already reported bug reports, go to https://bugzilla.kernel.org.
372 -------------
374 As some of the above documents describe, the majority of the core kernel
375 developers participate on the Linux Kernel Mailing list. Details on how
378 http://vger.kernel.org/vger-lists.html#linux-kernel
380 There are archives of the mailing list on the web in many different
383 http://dir.gmane.org/gmane.linux.kernel
387 already discussed in detail are only recorded at the mailing list
390 Most of the individual kernel subsystems also have their own separate
395 Many of the lists are hosted on kernel.org. Information on them can be
398 http://vger.kernel.org/vger-lists.html
410 to tune that by adding fancy mail-headers, people will not like it.
418 as stated in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
419 Kernel developers don't want to deal with
431 --------------------------
433 The goal of the kernel community is to provide the best possible kernel
438 - criticism
439 - comments
440 - requests for change
441 - requests for justification
442 - silence
444 Remember, this is part of getting your patch into the kernel. You have
449 again, sometimes things get lost in the huge volume.
453 - expect your patch to be accepted without question
454 - become defensive
455 - ignore comments
456 - resubmit the patch without making any of the requested changes
458 In a community that is looking for the best technical solution possible,
461 the kernel. Or at least be willing to prove your idea is worth it.
472 Differences between the kernel community and corporate structures
473 -----------------------------------------------------------------
475 The kernel community works differently than most traditional corporate
481 - "This solves multiple problems."
482 - "This deletes 2000 lines of code."
483 - "Here is a patch that explains what I am trying to describe."
484 - "I tested it on 5 different architectures..."
485 - "Here is a series of small patches that..."
486 - "This increases performance on typical machines..."
490 - "We did it this way in AIX/ptx/Solaris, so therefore it must be
492 - "I've being doing this for 20 years, so..."
493 - "This is required for my company to make money"
494 - "This is for our Enterprise product line."
495 - "Here is my 1000 page design document that describes my idea"
496 - "I've been working on this for 6 months..."
497 - "Here's a 5000 line patch that..."
498 - "I rewrote all of the current mess, and here it is..."
499 - "I have a deadline, and this patch needs to be applied now."
501 Another way the kernel community is different than most traditional
505 The Linux kernel work environment is accepting of women and minorities
509 Most women who have worked in the Linux kernel and have expressed an
513 comfortable with English. A good grasp of the language can be needed in
515 recommended that you check your emails to make sure they make sense in
520 ---------------------
522 The Linux kernel community does not gladly accept large chunks of code
526 should also be introduced very early in the development process, so that
548 and simplify (or simply re-order) patches before submitting them.
550 Here is an analogy from kernel developer Al Viro:
559 *The same is true of kernel development. The maintainers and
566 unfinished work. Therefore it is good to get early in the process to
567 get feedback to improve your work, but also keep your changes in small
576 -------------------
584 --------------------
586 When sending in your patches, pay special attention to what you say in
587 the text in your email. This information will become the ChangeLog
591 - why the change is necessary
592 - the overall design approach in the patch
593 - implementation details
594 - testing results
612 ----------
627 Maintainer: Greg Kroah-Hartman <greg@kroah.com>