Библиотека сайта rus-linux.net
The book is available and called simply "Understanding The Linux Virtual Memory Manager". There is a lot of additional material in the book that is not available here, including details on later 2.4 kernels, introductions to 2.6, a whole new chapter on the shared memory filesystem, coverage of TLB management, a lot more code commentary, countless other additions and clarifications and a CD with lots of cool stuff on it. This material (although now dated and lacking in comparison to the book) will remain available although I obviously encourge you to buy the book from your favourite book store :-) . As the book is under the Bruce Perens Open Book Series, it will be available 90 days after appearing on the book shelves which means it is not available right now. When it is available, it will be downloadable from http://www.phptr.com/perens so check there for more information.
To be fully clear, this webpage is not the actual book.
Next: 3. Describing Physical Memory Up: 2. Code Management Previous: 2.2 Getting Started Contents Index
2.3 Submitting Work
A quite comprehensive set of documents on the submission of patches is
available in the Documentation/ part of the kernel source tree and
it is important to read. There are two files SubmittingPatches and
CodingStyle which cover the important basics but there seems to be
very little documentation describing how to go about getting patches merged.
Hence, this section will give a brief introduction on how, broadly speaking,
patches are managed.
First and foremost, the coding style of the kernel needs to be adhered to as having a style inconsistent with the main kernel will be a barrier to getting merged regardless of the technical merit. Once a patch has been developed, the first problem is to decide where to send it. Kernel development has a definite, if non-apparent, hierarchy of who handles patches and how to get them submitted. As an example, we'll take the case of 2.5.x development.
The first check to make is if the patch is very small or trivial. If it is, post it to the main kernel mailing list. If there is no bad reaction, it can be fed to what is called the Trivial Patch Monkey2.7. The trivial patch monkey is exactly what it sounds like, it takes small patches and feeds them en-masse to the correct people. This is best suited for documentation, commentary or one-liner patches.
Patches are managed through what could be loosely called a set of rings with Linus in the very middle having the final say on what gets accepted into the main tree. Linus, with rare exceptions, accepts patches only from who he refers to as his ``lieutenants'', a group of around 10 people who he trusts to ``feed'' him correct code. An example lieutenant is Andrew Morton, the VM maintainer at time of writing. Any change to the VM has to be accepted by Andrew before it will get to Linus. These people are generally maintainers of a particular system but sometimes will ``feed'' him patches from another subsystem if they feel it is important enough.
Each of the lieutenants are active developers on different subsystems. Just
like Linus, they have a small set of developers they trust to be knowledgeable
about the patch they are sending but will also pick up patches which
affect their subsystem more readily. Depending on the subsystem, the
list of people they trust will be heavily influenced by the list of
maintainers in the MAINTAINERS file. The second major area of
influence will be from the subsystem specific mailing list if there is
one. The VM does not have a list of maintainers but it does have a mailing
list2.8.
The maintainers and lieutenants are crucial to the acceptance of patches. Linus, broadly speaking, does not appear to wish to be convinced with argument alone on the merit for a significant patch but prefers to hear it from one of his lieutenants, which is understandable considering the volume of patches that exists.
In summary, a new patch should be emailed to the subsystem mailing list cc'd
to the main list to generate discussion. If there is no reaction, it should
be sent to the maintainer for that area of code if there is one and to the
lieutenant if there is not. Once it has been picked up by a maintainer or
lieutenant, chances are it will be merged. The important key is that patches
and ideas must be released early and often so developers have a chance to
look at it while they are still manageable. There are notable cases where
massive patches had difficult getting merged because there were long periods
of silence with little or no discussions. A recent example of this is the
Linux Kernel Crash Dump project which still has not been merged into the
main stream because there has not been favorable responses from lieutenants
or strong support from vendors.
Footnotes
- ... Monkey2.7
- http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
- ... list2.8
- http://www.linux-mm.org/mailinglists.shtml
Next: 3. Describing Physical Memory Up: 2. Code Management Previous: 2.2 Getting Started Contents Index Mel 2004-02-15