Lines Matching +full:technical +full:- +full:articles
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
76 -------------
85 maintainer at alx@kernel.org, and CC the list linux-api@vger.kernel.org.
90 :ref:`Documentation/admin-guide/README.rst <readme>`
100 :ref:`Documentation/process/coding-style.rst <codingstyle>`
107 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
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>`
131 - Subsystem shim-layers (for compatibility?)
132 - Driver portability between Operating Systems.
133 - Mitigating rapid change within the kernel source tree (or
140 :ref:`Documentation/process/security-bugs.rst <securitybugs>`
145 :ref:`Documentation/process/management-style.rst <managementstyle>`
152 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
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
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
370 -------------
381 https://lore.kernel.org/linux-kernel/
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 --------------------------
433 on its technical merits and those alone. So, what should you be
436 - criticism
437 - comments
438 - requests for change
439 - requests for justification
440 - silence
444 them at a technical level and either rework your patches or provide
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
456 In a community that is looking for the best technical solution possible,
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 -------------------
582 --------------------
589 - why the change is necessary
590 - the overall design approach in the patch
591 - implementation details
592 - testing results
610 ----------
613 (https://lwn.net/Articles/94386/) section
625 Maintainer: Greg Kroah-Hartman <greg@kroah.com>