Lines Matching +refs:is +refs:post +refs:merge
6 This is the be-all, end-all document on this topic. It contains
13 to the maintainer of this file, who is listed at the bottom of the
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
28 parts written in assembly. A good understanding of C is required for
29 kernel development. Assembly (any architecture) is not required unless
38 The kernel is written using GNU C and the GNU toolchain. While it
40 not featured in the standard. The kernel is a freestanding C
45 and the extensions that it uses, and unfortunately there is no
50 existing development community. It is a diverse group of people, with
62 The Linux kernel source code is released under the GPL. Please see the file
80 new features are added to the kernel, it is recommended that new
83 userspace to change, it is recommended that you send the information or
88 Here is a list of files that are in the kernel source tree that are
93 what is necessary to do to configure and build the kernel. People
103 rationale behind it. All new code is expected to follow the
106 review code if it is in the proper style.
137 This document is crucial for understanding the Linux development
138 philosophy and is very important for people moving to Linux from
148 shared ethos behind their methodologies. This is important reading
164 A good introduction describing exactly what a patch is and how to
198 real-time, and a lot of helpful documentation that is useful for
212 It is a great place to start. It describes a list of relatively simple
219 Before making any actual modifications to the Linux kernel code, it is
221 purpose, nothing is better than reading through it directly (most tricky
223 tools. One such tool that is particularly recommended is the Linux
224 Cross-Reference project, which is able to present source code in a
246 The mainline tree is maintained by Linus Torvalds, and can be found at
247 https://kernel.org or in the repo. Its development process is as follows:
249 - As soon as a new kernel is released a two week window is open,
253 is using git (the kernel's source management tool, more information
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
263 outside of the code that is being added. git can be used to send
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
267 be in a reasonably sane state adequate for testing. The goal is to
269 - Process continues until the kernel is considered "ready", the
272 It is worth mentioning what Andrew Morton wrote on the linux-kernel
288 This is the recommended branch for users who want the most recent stable
293 are released as needs dictate. The normal release period is approximately
307 development in source repositories. That way, others can see what is
309 development is rapid, a developer may be asked to base his submissions
318 Before a proposed patch is committed to such a subsystem tree, it is
321 process is tracked with the tool patchwork. Patchwork offers a web
338 expected to go into the mainline kernel at the next merge period.
347 what kind of information is needed by the kernel developers to help track
354 One of the best ways to put into practice your hacking skills is by fixing
358 Fixing bugs is one of the best ways to get merits among other developers,
384 It is highly recommended that you search the archives about the topic
385 you want to bring up, before you post it to the list. A lot of things
422 good first test is to send the mail to yourself and try to apply your
432 The goal of the kernel community is to provide the best possible kernel
433 there is. When you submit a patch for acceptance, it will be reviewed
443 Remember, this is part of getting your patch into the kernel. You have
457 In a community that is looking for the best technical solution possible,
458 there will always be differing opinions on how beneficial a patch is.
460 the kernel. Or at least be willing to prove your idea is worth it.
461 Remember, being wrong is acceptable as long as you are willing to work
462 toward a solution that is right.
464 It is normal that the answers to your first patch might simply be a list
466 patch will not be accepted, and it is **not** meant against you
482 - "Here is a patch that explains what I am trying to describe."
484 - "Here is a series of small patches that..."
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"
497 - "I rewrote all of the current mess, and here it is..."
500 Another way the kernel community is different than most traditional
501 software engineering work environments is the faceless nature of
503 communication is the lack of discrimination based on gender or race.
504 The Linux kernel work environment is accepting of women and minorities
505 because all you are is an email address. The international aspect also
513 order to get ideas across properly on mailing lists, so it is
523 discussed, and broken up into tiny, individual portions. This is almost
538 review for correctness (the time it takes is exponentially
542 wrong. It's much easier to back out patches one by one than it is
549 Here is an analogy from kernel developer Al Viro:
558 *The same is true of kernel development. The maintainers and
560 solution to the problem one is solving. They want to see a
565 unfinished work. Therefore it is good to get early in the process to
567 chunks that they may get already accepted, even when your whole task is
570 Also realize that it is not acceptable to send patches for inclusion
577 Along with breaking up your patches, it is very important for you to let
590 - why the change is necessary