Next Previous Contents

8. Libraries and Conventions

8.1 Double-linked lists <include/linux/list.h>

There are three sets of linked-list routines in the kernel, but this one seems to be winning out (and Linus has used it). If you don't have some particular pressing need for a single list, it's a good choice.

8.2 Return conventions

For code called in user context, it's very common to defy C convention, and return 0 for success, and a negative error number (eg. -EFAULT) for failure. This can be unintuitive at first, but it's fairly widespread in the networking code, for example.

8.3 Breaking compilation

Linus sometimes changes function names in development kernels; he doesn't do this for fun: it reflects a fundamental change (eg. can no longer be called with interrupts on, or does extra checks, or doesn't do checks which were caught before). Usually this is accompanied by a fairly complete note to the linux-kernel mailing list; search the archive. Simply doing a global replace on the file usually makes things worse.

8.4 GNU Extentions

GNU Extentions are explicitly allowed in the Linux kernel. Note that some of the more complex ones are not very well supported, due to lack of general use, but the following are considered standard (see the GCC info page section "C Extensions" for more details - Yes, really the info page, the man page is only a short summary of the stuff in info):

[AK: FIXME There is a really great tutorial from Colin Plumb for gcc inline assembly around, I just don't have a stable URL for it. Perhaps someone on l-k can help]

Don't use long long in the kernel, the code gcc generates for it is horrible and worse division and multiplication does not work on i386 because the GCC runtime functions for it are missing from the kernel environment.

[FIXME: add a note about ANSI aliasing cleanness]

8.5 C++

Using C++ in the kernel is usually a bad idea, because the kernel does not provide the necessary runtime environment and the include files are not tested for it. It is still possible, but not recommended. If you really want to do this, forget about exceptions at least.

8.6 #if

It is generally considered cleaner to use macros in header files (or at the top of .c files) to abstract away functions rather than using `#if' pre-processor statements throughout the source code.

Next Previous Contents