Linux Kernel Architecture

Mauerer runbapp06.tex V1 - 09/04/2008 6:14pm Page 1278

Appendix F: The Kernel Development Process

❑ The code itself should be directly present in the e-mail, without using any form of base64

encoding, compression, or other fancy tricks. Attachments are also not particularly favored, and

the preferred way is to include the code directly. Any material that should be included in the

description but is not supposed to go into the repository must be separated from the patch by

three dashes on a single line.

Naturally, the code should not be line-wrapped by the e-mail client as there are rumors that

compilers sometimes have a veryhard time accepting randomly wrapped code. And after all

that has been said, a remark that HTML e-mails are inappropriate is likely superfluous.

Below the e-mail subject lines of the submission of an experimental patch are shown. They obey all the

conventions discussed before:

[PATCH 0/4] [RFC] Verification and debugging of memory initialisationMel Gorman(Wed Apr 16 2008

• 09:51:19 EST)
  [PATCH 1/4] Add a basic debugging framework for memory initialisationMel Gorman(Wed Apr 16
  2008 - 09:51:32 EST)
  [PATCH 2/4] Verify the page links and memory modelMel Gorman(Wed Apr 16 2008 - 09:51:53 EST)
  [PATCH 3/4] Print out the zonelists on request for manual verificationMel Gorman(Wed Apr 16
  2008 - 09:52:22 EST)
  [PATCH 4/4] Make defencive checks around PFN values registered for memory usageMel Gorman(Wed
  Apr 16 2008 - 09:52:37 EST)

Notice that the four messages containing the actual code have been posted as replies to the first, intro-

ductory message. This allows many mailer clients to group the posts, which makes it easier to recognize

the patches as one entity.

Take a look at the contents of the first mail:

This patch creates a new file mm/mm_init.c which memory initialisation should

be moved to over time to avoid further polluting page_alloc.c. This patch

introduces a simple mminit_debug_printk() function and an (undocumented)

mminit_debug_level command-line parameter for setting the level of tracing

and verification that should be done.

Signed-off-by: Mel Gorman <mel@xxxxxxxxx>

---

mm/Makefile | 2 +-

mm/internal.h | 9 +++++++++

mm/mm_init.c | 40 ++++++++++++++++++++++++++++++++++++++++

mm/page_alloc.c | 16 ++++++++++------

4 files changed, 60 insertions(+), 7 deletions(-)

(PATCH)

After an overview about the code, the diff statistics produced bydiffstatare attached. These allow to

quickly identify how many changes a patch introduces in terms of added and deleted lines, and where

these changes are bound to happen. This statistical information is interesting for discussion of the code,

but has no purpose in long-term changelogs (after all, the information can be generated from the patch),

so it is placed after a three-dash line. This is followed by the patch as generated bydiff, but as this is not

relevant to this discussion, it is not reproduced here.