Lines Matching +full:technical +full:- +full:documentation
6 This is the be-all, end-all document on this topic. It contains
9 contain anything related to the technical aspects of kernel programming,
18 ------------
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 ------------
65 described in :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
72 https://www.gnu.org/licenses/gpl-faq.html
75 Documentation section in HOWTO do Linux kernel development
76 -------------
81 documentation files are also added which explain how to use the feature.
86 linux-api@vger.kernel.org.
91 :ref:`Documentation/admin-guide/README.rst <readme>`
96 :ref:`Documentation/process/changes.rst <changes>`
101 :ref:`Documentation/process/coding-style.rst <codingstyle>`
108 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
112 - Email contents
113 - Email format
114 - Who to send it to
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>`
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>`
146 :ref:`Documentation/process/management-style.rst <managementstyle>`
153 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
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>`
170 full description of the in-kernel API, and rules on how to handle
180 The documents that uses ReST markup will be generated at Documentation/output.
187 ---------------------------
198 real-time, and a lot of helpful documentation that is useful for
202 and current projects (both in-tree and out-of-tree). It also describes
224 Cross-Reference project, which is able to present source code in a
225 self-referential, indexed webpage format. An excellent up-to-date
232 -----------------------
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
249 - As soon as a new kernel is released a two week window is open,
252 linux-next for a few weeks. The preferred way to submit big changes
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
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
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
282 Kernels with 3-part versions are -stable kernels. They contain
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>`
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
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
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
352 --------------------
371 -------------
377 http://vger.kernel.org/vger-lists.html#linux-kernel
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>`.
430 --------------------------
434 on its technical merits and those alone. So, what should you be
437 - criticism
438 - comments
439 - requests for change
440 - requests for justification
441 - silence
445 them at a technical level and either rework your patches or provide
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,
472 -----------------------------------------------------------------
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."
519 ---------------------
547 and simplify (or simply re-order) patches before submitting them.
575 -------------------
583 --------------------
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>