Linux Kernel Architecture

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

Appendix F: The Kernel Development Process

* Catch too large forward jumps too:

*/

if (unlikely(clock + delta > rq->tick_timestamp + TICK_NSEC)) {

if (clock < rq->tick_timestamp + TICK_NSEC)

clock = rq->tick_timestamp + TICK_NSEC;

else

clock++;

rq->clock_overflows++;

} else {

if (unlikely(delta > rq->clock_max_delta))

rq->clock_max_delta = delta;

clock += delta;

}

}

rq->prev_clock_raw = now;

rq->clock = clock;

}

❑ No surrounding space should be used inside parentheses, soif ( condition )is frowned upon,

whileif (condition)will be universally loved. Keywords likeifare followed by a space,

whereas function definitions and functions calls are not. The preceding code excerpt also con-

tains examples of these rules.

❑ Constants should be represented by macros or elements inenumenumerations, and their names

should be in all capital letters.

❑ Functions should typically not be longer than one screen (i.e., 24 lines). Longer code should be

broken into multiple functions, even if the resulting auxiliary functions will have only a single

caller.

❑ Local variable names should be short (and firm), and not tell the story of a complete novel like

OnceUponATimeThereWasACounterWhichMustBeIntializedWithZero. You can also usetmp,

which also protects you from breaking your fingers during interaction with the keyboard.

Globalidentifiers should tell a little more about themselves because they are visible in all con-

texts.prio_tree_removeis a fine name for a global function, whereascurandretare only apt

for local variable names. Names composed of multiple expressions should use underscores to

separate the constituents, and not employ mixed lower/uppercase letters.

❑ Typedefs are considered to be an incarnation of the devil because they hide the actual definition

of an object, so they should usually not be employed. It might save the creator of a patch some

typing, but will make reading harder for all other developers.

However, sometimes itisnecessary to hide the definition of a data type, such as when a quantity

must be implemented differently depending on the underlying architecture, but common code

should not notice this. For instance, consider theatomic_ttype used for atomic counters, or

the various page table elements likepte_t,pud_t, and so on. They must not be accessed and

modified directly, but only via special auxiliary functions, so their definitionmust notbe visible

to generic code.

All these rules and more are discussed in depth in the coding style documentDocumentation/
CodingStyle, together with the rationale behind them (including the all-important rule number 17:
Don’t re-invent the wheel!) Accordingly, it does not make sense to repeat the information in the