Linux Kernel Architecture

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

Appendix A: Architecture Specifics.........................................

Memory management also employs a variety of interface functions and definitions — to specify page

size or to update caches, for instance.

This chapter is designed to give a brief summary of how various system-specific tasks are performed on

the most popular architectures supported by the kernel. This is based on the fact that the kernel must

exploit a very large number of hardware features that differ from processor to processor and require

in-depth knowledge of the individual architectures. Considering that each processor family is typically

accompanied by a reference manual of a thousand pages or more to describe architectural subtleties and

oddities, this book cannot even begin to examine every little detail of importance to the kernel. Instead,

this chapter sketches out the rough structure that supports the Linux port to a specific architecture. This

book also describes various special features of some of the ports.

The build system takes into account the need to resort to architecture-specific defined mechanisms at

various points in the generic code. All processor-specific header files are located ininclude/asm-arch.

Once the kernel has been configured for a specific architecture, a symbolic link (namedinclude/asm)

to the appropriate machine-specific directory is created; for example, this link would beinclude/asm

-> include/asm-alphaon an Alpha AXP system. This enables the kernel to link in architecture-specific

headers by means of#include<asm/file.h>.

This book gives only a brief overview of the standard headers that must be made available by the indi-

vidual ports and of the functions and definitions these headers must declare (and also implement). It

would require another entire book to cover the details of each architecture supported.

A.2 Data Types

The kernel makes a basic distinction between the following three elementary data types:

❑ Standard data types as used in every C program; for example,unsigned long,void *,and

char. The number of bits that these types have is not fixed by the C standard. Only various

inequalities are guaranteed; for instance,unsigned longhas at least as many if not more bits

thanint.

In terms of portability, it should be noted that the bit size of standard data types can differ

between architectures.

❑ Data types with a fixed number of bits. The kernel provides special integer data types with

names likeu32ands16for unsigned (u)andsigned(s) integers with a predefined number of

bits. The individual architectures must definethe abbreviations in such a way that they can be

mapped (usingtypedef) to corresponding elementary data types.

❑ Subsystem-specific types that are never manipulated directly but always by specially written

functions. Converting the data type definition is easy, because all subsystems that use any of

these data types are never able to manipulate them directly but must delegate this task to the

specific subsystem. Only the standard manipulation functions need to be modified; the remain-

ing kernel parts remain unchanged.

Examples of subsystem-specific data types arepid_tfor managing pids andsector_tfor iden-

tifying sector numbers.

The data types with a fixed number of bits are defined in<asm-arch/types.h>.