Lines Matching +full:in +full:- +full:kernel
1 HOWTO do Linux kernel development
4 This is the be-all, end-all document on this topic. It contains
5 instructions on how to become a Linux kernel developer and how to learn
6 to work with the Linux kernel development community. It tries to not
7 contain anything related to the technical aspects of kernel programming,
8 but will help point you in the right direction for that.
10 If anything in this document becomes out of date, please send in patches
16 ------------
18 So, you want to learn how to become a Linux kernel developer? Or you
25 The kernel is written mostly in C, with some architecture-dependent
26 parts written in assembly. A good understanding of C is required for
27 kernel development. Assembly (any architecture) is not required unless
28 you plan to do low-level development for that architecture. Though they
32 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
33 - "Practical C Programming" by Steve Oualline [O'Reilly]
34 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
36 The kernel is written using GNU C and the GNU toolchain. While it
38 not featured in the standard. The kernel is a freestanding C
42 difficult to understand the assumptions the kernel has on the toolchain
58 ------------
60 The Linux kernel source code is released under the GPL. Please see the
61 file, COPYING, in the main directory of the source tree, for details on
63 contact a lawyer, and do not ask on the Linux kernel mailing list. The
69 https://www.gnu.org/licenses/gpl-faq.html
73 -------------
75 The Linux kernel source tree has a large range of documents that are
76 invaluable for learning how to interact with the kernel community. When
77 new features are added to the kernel, it is recommended that new
79 When a kernel change causes the interface that the kernel exposes to
83 linux-api@vger.kernel.org.
85 Here is a list of files that are in the kernel source tree that are
88 :ref:`Documentation/admin-guide/README.rst <readme>`
89 This file gives a short background on the Linux kernel and describes
90 what is necessary to do to configure and build the kernel. People
91 who are new to the kernel should start here.
95 packages that are necessary to build and run the kernel
98 :ref:`Documentation/process/coding-style.rst <codingstyle>`
99 This describes the Linux kernel coding style, and some of the
101 guidelines in this document. Most maintainers will only accept
103 review code if it is in the proper style.
105 …:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/pr…
106 These files describe in explicit detail how to successfully create
109 - Email contents
110 - Email format
111 - Who to send it to
122 "Linux kernel patch submission format"
123 http://linux.yyz.us/patch-format.html
125 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
127 not have a stable API within the kernel, including things like:
129 - Subsystem shim-layers (for compatibility?)
130 - Driver portability between Operating Systems.
131 - Mitigating rapid change within the kernel source tree (or
138 :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
139 If you feel you have found a security problem in the Linux kernel,
140 please follow the steps in this document to help notify the kernel
143 :ref:`Documentation/process/management-style.rst <managementstyle>`
144 This document describes how Linux kernel maintainers operate and the
146 for anyone new to kernel development (or anyone simply curious about
148 about the unique behavior of kernel maintainers.
150 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
151 This file describes the rules on how the stable kernel releases
155 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
156 A list of external documentation that pertains to kernel
158 are looking for within the in-kernel documentation.
160 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
162 apply it to the different development branches of the kernel.
164 The kernel also has a large number of documents that can be
167 full description of the in-kernel API, and rules on how to handle
175 respectively from the main kernel source directory.
183 Becoming A Kernel Developer
184 ---------------------------
186 If you do not know anything about Linux kernel development, you should
192 of basic kernel development question (make sure to search the archives
193 first, before asking something that has already been answered in the
194 past.) It also has an IRC channel that you can use to ask questions in
195 real-time, and a lot of helpful documentation that is useful for
196 learning about Linux kernel development.
199 and current projects (both in-tree and out-of-tree). It also describes
200 some basic logistical information, like how to compile a kernel and
204 some task to start doing to join into the kernel development community,
205 go to the Linux Kernel Janitor's project:
210 problems that need to be cleaned up and fixed within the Linux kernel
211 source tree. Working with the developers in charge of this project, you
212 will learn the basics of getting your patch into the Linux kernel tree,
213 and possibly be pointed in the direction of what to go work on next, if
216 Before making any actual modifications to the Linux kernel code, it is
217 imperative to understand how the code in question works. For this
221 Cross-Reference project, which is able to present source code in a
222 self-referential, indexed webpage format. An excellent up-to-date
223 repository of the kernel code may be found at:
225 http://lxr.free-electrons.com/
229 -----------------------
231 Linux kernel development process currently consists of a few different
232 main kernel "branches" and lots of different subsystem-specific kernel
235 - main 4.x kernel tree
236 - 4.x.y -stable kernel tree
237 - 4.x -git kernel patches
238 - subsystem specific kernel trees and patches
239 - the 4.x -next kernel tree for integration tests
241 4.x kernel tree
245 https://kernel.org in the pub/linux/kernel/v4.x/ directory. Its development
248 - As soon as a new kernel is released a two weeks window is open,
250 Linus, usually the patches that have already been included in the
251 -next kernel 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
278 4.x.y -stable kernel tree
281 Kernels with 3-part versions are -stable kernels. They contain
283 regressions discovered in a given 4.x kernel.
286 kernel and are not interested in helping test development/experimental
289 If no 4.x.y kernel is available, then the highest numbered 4.x
290 kernel is the current stable kernel.
292 4.x.y 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 Documentation/process/stable-kernel-rules.rst in the kernel tree
299 documents what kinds of changes are acceptable for the -stable tree, and
302 4.x -git patches
305 These are daily snapshots of Linus' kernel tree which are managed in a
308 experimental than -rc kernels since they are generated automatically
311 Subsystem Specific kernel trees and patches
314 The maintainers of the various kernel subsystems --- and also many
315 kernel subsystem developers --- expose their current state of
316 development in source repositories. That way, others can see what is
317 happening in the different areas of the kernel. In areas where
319 onto such a subsystem kernel tree so that conflicts between the
323 in use, or patch queues being published as quilt series. Addresses of
324 these subsystem repositories are listed in the MAINTAINERS file. Many
325 of them can be browsed at https://git.kernel.org/.
329 respective section below). For several kernel subsystems, this review
334 https://patchwork.kernel.org/.
336 4.x -next kernel tree for integration tests
340 tree, they need to be integration-tested. For this purpose, a special
344 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
346 This way, the -next kernel gives a summary outlook onto what will be
347 expected to go into the mainline kernel at the next merge period.
348 Adventurous testers are very welcome to runtime-test the -next kernel.
352 -------------
354 https://bugzilla.kernel.org is where the Linux kernel developers track kernel
355 bugs. Users are encouraged to report all bugs that they find in this
356 tool. For details on how to use the kernel bugzilla, please see:
358 https://bugzilla.kernel.org/page.cgi?id=faq.html
360 The file admin-guide/reporting-bugs.rst in the main kernel source directory has a good
361 template for how to report a possible kernel bug, and details what kind
362 of information is needed by the kernel developers to help track down the
367 --------------------
370 bugs reported by other people. Not only you will help to make the kernel
376 To work in the already reported bug reports, go to https://bugzilla.kernel.org.
380 -------------
382 As some of the above documents describe, the majority of the core kernel
383 developers participate on the Linux Kernel Mailing list. Details on how
386 http://vger.kernel.org/vger-lists.html#linux-kernel
388 There are archives of the mailing list on the web in many different
391 http://dir.gmane.org/gmane.linux.kernel
395 already discussed in detail are only recorded at the mailing list
398 Most of the individual kernel subsystems also have their own separate
403 Many of the lists are hosted on kernel.org. Information on them can be
406 http://vger.kernel.org/vger-lists.html
418 to tune that by adding fancy mail-headers, people will not like it.
426 as stated in Documentation/process/submitting-patches.rst.
427 Kernel developers don't want to deal with
439 --------------------------
441 The goal of the kernel community is to provide the best possible kernel
446 - criticism
447 - comments
448 - requests for change
449 - requests for justification
450 - silence
452 Remember, this is part of getting your patch into the kernel. You have
457 again, sometimes things get lost in the huge volume.
461 - expect your patch to be accepted without question
462 - become defensive
463 - ignore comments
464 - resubmit the patch without making any of the requested changes
466 In a community that is looking for the best technical solution possible,
469 the kernel. Or at least be willing to prove your idea is worth it.
480 Differences between the kernel community and corporate structures
481 -----------------------------------------------------------------
483 The kernel community works differently than most traditional corporate
489 - "This solves multiple problems."
490 - "This deletes 2000 lines of code."
491 - "Here is a patch that explains what I am trying to describe."
492 - "I tested it on 5 different architectures..."
493 - "Here is a series of small patches that..."
494 - "This increases performance on typical machines..."
498 - "We did it this way in AIX/ptx/Solaris, so therefore it must be
500 - "I've being doing this for 20 years, so..."
501 - "This is required for my company to make money"
502 - "This is for our Enterprise product line."
503 - "Here is my 1000 page design document that describes my idea"
504 - "I've been working on this for 6 months..."
505 - "Here's a 5000 line patch that..."
506 - "I rewrote all of the current mess, and here it is..."
507 - "I have a deadline, and this patch needs to be applied now."
509 Another way the kernel community is different than most traditional
513 The Linux kernel work environment is accepting of women and minorities
517 Most women who have worked in the Linux kernel and have expressed an
521 comfortable with English. A good grasp of the language can be needed in
523 recommended that you check your emails to make sure they make sense in
528 ---------------------
530 The Linux kernel community does not gladly accept large chunks of code
534 should also be introduced very early in the development process, so that
556 and simplify (or simply re-order) patches before submitting them.
558 Here is an analogy from kernel developer Al Viro:
567 *The same is true of kernel development. The maintainers and
574 unfinished work. Therefore it is good to get early in the process to
575 get feedback to improve your work, but also keep your changes in small
584 -------------------
592 --------------------
594 When sending in your patches, pay special attention to what you say in
595 the text in your email. This information will become the ChangeLog
599 - why the change is necessary
600 - the overall design approach in the patch
601 - implementation details
602 - testing results
620 ----------
635 Maintainer: Greg Kroah-Hartman <greg@kroah.com>