Linux Kernel Architecture

Mauerer runapp01.tex V1 - 09/04/2008 6:08pm Page 1117

Architecture Specifics

One of the key benefits of the kernel is the fact that it is mostly architecture-independent.Because

the majority of the sources are written in C, the implemented algorithms are not tied to a par-

ticular CPU or computer family but can, in principle, be ported to on any platform with modest

effort — assuming that a suitable C compiler is available. Inevitably, the kernel must provide inter-

faces to the underlying hardware, perform various system-specific tasks that involve countless

details, and exploit the special functions of the processors used. These must generally be written

in an assembly language. However, there are also some architecture specific data structures that

are defined in C, so architecture-specific does not necessarily equate to assembler-specific. This

appendix describes some hardware-specific aspects of important Linux ports.

A.1 Overview

To facilitate extensibility on new architectures,the kernel strictly segregates architecture-dependent

and architecture-independentcode. Theinclude/asm-arch/directory holds header files that contain

the definitions and prototypes for processor-specific elements of the kernel, whereas C and assem-

bler source codes that implement the machine-specific part of the kernel reside inarch/arch/.

Together these occupy on average between 1 and 3 MiB in the kernel sources of each architecture.

Although this represents a fair amount of code, it is nevertheless relatively compact for a complete

abstraction layer.

There are basically two categories of architecture-specific code:

❑ Components that are used and invoked exclusively by the architecture-specific parts of the

kernel. As far as the rest of the code is concerned, the location of this code and the functions

that are called are irrelevant.

❑ Interface functions thatmustbe defined by every architecture as they are invoked by

architecture-independent code. For example, each port must provide aswitch_tofunction

to take care of hardware-control details when switching between two processes. The

scheduler makes use of this function by deciding —regardlessof the architecture — which

task runs next and then delegating the actual task switch to processor-specific code.