Lines Matching +full:document +full:- +full:file
6 This is the be-all, end-all document on this topic. It contains
12 If anything in this document becomes out of date, please send in patches
13 to the maintainer of this file, who is listed at the bottom of the
14 document.
18 ------------
22 device." This document's goal is to teach you everything you need to
27 The kernel is written mostly in C, with some architecture-dependent
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]
60 ------------
62 The Linux kernel source code is released under the GPL. Please see the file
65 described in :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
72 https://www.gnu.org/licenses/gpl-faq.html
76 -------------
85 maintainer at alx@kernel.org, and CC the list linux-api@vger.kernel.org.
90 :ref:`Documentation/admin-guide/README.rst <readme>`
91 This file gives a short background on the Linux kernel and describes
96 This file gives a list of the minimum levels of various software
100 :ref:`Documentation/process/coding-style.rst <codingstyle>`
103 guidelines in this document. Most maintainers will only accept
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
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>`
128 This file describes the rationale behind the conscious decision to
131 - Subsystem shim-layers (for compatibility?)
132 - Driver portability between Operating Systems.
133 - Mitigating rapid change within the kernel source tree (or
136 This document is crucial for understanding the Linux development
140 :ref:`Documentation/process/security-bugs.rst <securitybugs>`
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
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>`
160 are looking for within the in-kernel documentation.
162 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
169 full description of the in-kernel API, and rules on how to handle
186 ---------------------------
197 real-time, and a lot of helpful documentation that is useful for
201 and current projects (both in-tree and out-of-tree). It also describes
223 Cross-Reference project, which is able to present source code in a
224 self-referential, indexed webpage format. An excellent up-to-date
231 -----------------------
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
248 - As soon as a new kernel is released a two week window is open,
251 linux-next for a few weeks. The preferred way to submit big changes
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
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
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
281 Kernels with 3-part versions are -stable kernels. They contain
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>`
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
314 these subsystem repositories are listed in the MAINTAINERS file. Many
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
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
351 --------------------
355 more stable, but you'll also learn to fix real-world problems and you will
361 Check the MAINTAINERS file where bugs for that subsystem get reported to; often
370 -------------
381 https://lore.kernel.org/linux-kernel/
390 MAINTAINERS file for a list of what these lists are for the different
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>`.
429 --------------------------
436 - criticism
437 - comments
438 - requests for change
439 - requests for justification
440 - silence
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
471 -----------------------------------------------------------------
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."
518 ---------------------
546 and simplify (or simply re-order) patches before submitting them.
574 -------------------
581 Document your change
582 --------------------
589 - why the change is necessary
590 - the overall design approach in the patch
591 - implementation details
592 - testing results
595 ChangeLog section of the document:
610 ----------
621 document would not have been possible.
625 Maintainer: Greg Kroah-Hartman <greg@kroah.com>