Linux Kernel Architecture

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

Appendix F: The Kernel Development Process

Coding Style

The kernel has some coding style requirements, which are defined inDocumentation/CodingStyle.

Although not all developers agree about each requirement in this file, many are very sensitive about

coding-style violations. Having a common coding style is a good thing. The kernel contains vast amounts

of code, and digging through patches and files that use all different conventions can become a real nui-

sance. Thankfully, the kernel displays less-religious zeal about coding style than other projects, but there

is a clear opinion on what is not the ultimate fashionable style, as you can see in the following documen-

tation snippet:

Documentation/CodingStyle

First off, I’d suggest printing out a copy of the GNU coding standards,

and NOT read it. Burn them, it’s a great symbolic gesture.

But what do developers expect? The essential points are as follows:

❑ Different levels are always one tab apart, and one tab is always eight spaces long. This might

seem quite excessive for programmers who’ve had much exposure to userland code before, but

this is different in the kernel world. Naturally, code will tend to shift quickly to the right side

of the screen after a few indentation levels, but this serves as a warning sign: Code that needs

too many levels of indention should usually be replaced with something cleaner, or be split into

functions, and then the problem will automatically go away.

Large indentations often cause strings and procedure arguments to exceed the 80-column

boundary, and they must be sensibly broken into chunks. You have seen numerous examples of

this all over the book.

In addition to the aforementioned reasons, many kernel developers tend to have rather unusual

working practices, and long hacking sessions are not uncommon. After having written tons

of beautiful code three days in a row without a break, vision tends to get blurred, and large

indentations do definitely help in this situation (along with copious amounts of caffeinated

beverages).

❑ Opening braces are put last on the line they are contained in, and closing braces are put first on

their line. When a control statement is continued (as forelsebranches, orwhileconditionals

indoloops), the continuation statement is not put on a new line, but after the closing brace. If a

block contains only a single statement, no extra braces are necessary. In fact, they are even dis-

couraged (just think of how much typing you willsave over your whole life by this convention).

Functions follow a separate convention: The opening and closing brackets are both on

separate lines.

The following code contains examples for the above rules:

kernel/sched.c

static void __update_rq_clock(struct rq *rq)

{

u64 prev_raw = rq->prev_clock_raw;

u64 now = sched_clock();

...

if (unlikely(delta < 0)) {

clock++;

rq->clock_warps++;

} else {

/*