Наши партнеры

After this documentation was released in July 2003, I was approached
by Prentice Hall and asked to write a book on the Linux VM under the Bruce Peren's Open Book Series.

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.

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.