Linux Kernel Architecture

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

Appendix F: The Kernel Development Process

coding style here — the document comes with every kernel, so go and enjoy it there! Besides, when

reading through the kernel sources, you will familiarize with the desired style very quickly.

The following two utilities can help to obey the desired coding style:

❑ Lindent, located in the kernel’sscripts/directory, feeds GNUindentwith command-line

options to re-indent a file according to the indentation settings preferred by the kernel.

❑ checkpatch.pl, likewise located in thescripts/directory of the kernel source tree, scans a

patch for violations of the coding style and can provide appropriate diagnostics.

Portability

The kernel runs across a wide range of architectures, and these differ widely in the various restrictions

they impose on C code. One of the prerequisites for new code is that it is portable and will run on all

supported architectures as far as this is possible in principle. This book has previously covered the dif-

ferences between architectures and ways to circumvent those differences. Here is a reminder of some

important issues that must be considered when code is written for the kernel:

❑ Use proper locking to ensure that your code runs safe in multiprocessor environments. Thanks

to the preemptible kernel, this is also important on uniprocessor systems.

❑ Always write code that is neutral with respect to endianess. Your code must function on both

little and big endian machines.

❑ Do not assume that page frames are 4 KiB in size, but employPAGE_SIZEinstead.

❑ Do not assume any specific bit widths for any data type. When a fixed number of bits is required,

always use explicitely sized types likeu16,s64,andsoon.However,youcanalwaysassumethat

sizeof(long) == sizeof(void *).

❑ Do not use floating point calculations.

❑ Keep in mind that the stack size is fixed and limited.

DocumentingCode

In addition to documenting patch submissions, it is also important to document your code — especially

functions that can be called from other subsystems ordrivers. The kernel uses the following special form

of C comments for this purpose:

fs/char_dev.c

/**

* register_chrdev() - Register a major number for character devices.

* @major: major device number or 0 for dynamic allocation

* @name: name of this range of devices

* @fops: file operations associated with this devices

*

* If @major == 0 this functions will dynamically allocate a major and return

* its number.

*

* If @major > 0 this function will attempt to reserve a device with the given

* major number and will return zero on success.

*

* Returns a -ve errno on failure.