Lines Matching refs:and
5 instructions on how to become a Linux kernel developer and how to learn
22 and hints on how to work with the community. It will also try to
29 are not a good substitute for a solid C education and/or years of
31 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
33 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
35 The kernel is written using GNU C and the GNU toolchain. While it
40 divisions and floating point are not allowed. It can sometimes be
42 and the extensions that it uses, and unfortunately there is no
48 high standards for coding, style and procedure. These standards have
50 such a large and geographically dispersed team. Try to learn as much as
62 contact a lawyer, and do not ask on the Linux kernel mailing list. The
63 people on the mailing lists are not lawyers, and you should not rely on
66 For common questions and answers about the GPL, please see:
80 maintainer at mtk.manpages@gmail.com, and CC the list
86 This file gives a short background on the Linux kernel and describes
87 what is necessary to do to configure and build the kernel. People
92 packages that are necessary to build and run the kernel
96 This describes the Linux kernel coding style, and some of the
99 patches if these rules are followed, and many people will only
105 and send a patch, including (but not limited to):
110 subject to scrutiny for content and style), but not following them
127 philosophy and is very important for people moving to Linux from
133 developers, and help solve the issue.
136 This document describes how Linux kernel maintainers operate and the
139 it), as it resolves a lot of common misconceptions and confusion
144 happen, and what to do if you want to get a change into one of these
153 A good introduction describing exactly what a patch is and how to
158 full description of the in-kernel API, and rules on how to handle
160 Documentation/DocBook/ directory and can be generated as PDF,
161 Postscript, HTML, and man pages by running:
179 real-time, and a lot of helpful documentation that is useful for
183 and current projects (both in-tree and out-of-tree). It also describes
184 some basic logistical information, like how to compile a kernel and
192 problems that need to be cleaned up and fixed within the Linux kernel
195 and possibly be pointed in the direction of what to go work on next, if
201 mailing list, and can be found at:
219 main kernel "branches" and lots of different subsystem-specific kernel
224 - subsystem specific kernel trees and patches
229 4.x kernels are maintained by Linus Torvalds, and can be found on
244 is self-contained and does not affect areas outside of the code that
268 relatively small and critical fixes for security problems or significant
272 kernel and are not interested in helping test development/experimental
278 4.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
285 documents what kinds of changes are acceptable for the -stable tree, and
292 daily and represent the current state of Linus' tree. They are more
296 Subsystem Specific kernel trees and patches
298 The maintainers of the various kernel subsystems --- and also many
304 submission and other already ongoing work are avoided.
316 revisions to it, and maintainers can mark patches as under review,
342 template for how to report a possible kernel bug, and details what kind
352 more stable, you'll learn to fix real world problems and you will improve
353 your skills, and other developers will be aware of your presence. Fixing
372 to subscribe and unsubscribe from the list can be found at:
399 mail twice, one from the sender and the one from the list, and don't try
402 Remember to keep the context and the attribution of your replies intact,
403 keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
411 Make sure you use a mail program that does not mangle spaces and tab
412 characters. A good first test is to send the mail to yourself and try
424 on its technical merits and those alone. So, what should you be
433 to be able to take criticism and comments about your patches, evaluate
434 them at a technical level and either rework your patches or provide
435 clear and concise reasoning as to why those changes should not be made.
436 If there are no responses to your posting, wait a few days and try
447 You have to be cooperative, and willing to adapt your idea to fit within
454 patch will not be accepted, and it is _not_ meant against you
455 personally. Simply correct all issues raised against your patch and
459 Differences between the kernel community and corporate structures
482 - "I rewrote all of the current mess, and here it is..."
483 - "I have a deadline, and this patch needs to be applied now."
487 interaction. One benefit of using email and irc as the primary forms of
489 The Linux kernel work environment is accepting of women and minorities
492 a person's name. A man may be named Andrea and a woman may be named Pat.
493 Most women who have worked in the Linux kernel and have expressed an
508 discussed, and broken up into tiny, individual portions. This is almost
512 community feel that you are working with them, and not simply using them
528 to dissect a very large patch after it's been applied (and broken
532 and simplify (or simply re-order) patches before submitting them.
536 teacher does not want to see the student's trials and errors
538 cleanest, most elegant answer. A good student knows this, and
542 The same is true of kernel development. The maintainers and
545 simple and elegant solution."
548 solution and working together with the community and discussing your
555 that are unfinished and will be "fixed up later."
563 must be justified as being needed and useful.
571 information for the patch, and will be preserved for everyone to see for
588 improvement that requires a lot of patience and determination. But
589 don't give up, it's possible. Many have done it before, and each had to
598 to be based on text he had written, and to Randy Dunlap and Gerrit
599 Huizenga for some of the list of things you should and should not say.
603 David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
604 their review, comments, and contributions. Without their help, this