Architecture-Specific Implementation

Relevant source files

The following files were used as context for generating this wiki page:

• Documentation/kernel-hacking/hacking.rst
• Documentation/process/howto.rst
• Documentation/process/4.Coding.rst
• Documentation/arch/arm/index.rst
• Documentation/doc-guide/kernel-doc.rst
• arch/x86/include/asm/cpu.h
• Documentation/core-api/real-time/architecture-porting.rst

Architecture-specific implementation encompasses code and documentation tailored to specific CPU architectures within the Linux kernel. The kernel maintains portability by encapsulating CPU-specific details, such as inline assembly and memory management unit (MMU) configurations, within designated architecture directories.

Developers must minimize architecture-specific code in generic subsystems to ensure the kernel remains maintainable across different platforms. Proper implementation involves using standard kernel APIs for endian conversion, atomic operations, and memory access, while restricting hardware-specific logic to the arch/ and include/asm/ directories.

Sources: Documentation/kernel-hacking/hacking.rst:147-152, Documentation/process/howto.rst:49-51

Portability and Encapsulation

The Linux kernel maintains portability by isolating architecture-dependent code. Generic code should not contain inline assembly; instead, developers must encapsulate such instructions within the architecture-dependent part of the kernel tree.

Portability Guidelines

• Write 64-bit clean code.
• Ensure endian-independence using kernel conversion functions.
• Minimize CPU-specific logic in generic files.
• Use designated directories like arch/<arch>/ for platform-specific routines.

Sources: Documentation/kernel-hacking/hacking.rst:147-152, Documentation/process/4.Coding.rst:146-150

The diagram shows how generic subsystems access hardware through an architecture-specific abstraction layer.
Sources: Documentation/kernel-hacking/hacking.rst:147-152, Documentation/arch/arm/index.rst

Endian and Byte Order Management

Different CPU architectures use different byte orders (Big Endian or Little Endian). The kernel provides a family of macros to handle these conversions safely across all platforms.

Macro Type	Purpose	Source File
cpu_to_be32()	Converts CPU order to Big Endian (32-bit)	include/asm/byteorder.h
be32_to_cpu()	Converts Big Endian to CPU order (32-bit)	include/asm/byteorder.h
cpu_to_le32()	Converts CPU order to Little Endian (32-bit)	include/asm/byteorder.h
cpu_to_be32p()	Pointer variation for endian conversion	include/asm/byteorder.h

Sources: Documentation/kernel-hacking/hacking.rst:312-325

Atomic Operations and Bit Manipulation

Architecture-specific implementations provide guaranteed atomic operations for integers and bits. These are critical for synchronization in multiprocessor (SMP) environments.

Atomic Integers

The atomic_t type, defined in include/asm/atomic.h, represents a signed integer of at least 32 bits. Developers must use specific functions like atomic_read(), atomic_set(), and atomic_inc() to manipulate these variables.

Bit Operations

Atomic bit operations are defined in include/linux/bitops.h. These operations work on unsigned long values. On big-endian platforms, behavior can be inconsistent if bit indices exceed BITS_PER_LONG.

• set_bit(): Sets a specific bit.
• clear_bit(): Clears a specific bit.
• test_and_set_bit(): Sets a bit and returns its previous value.

Sources: Documentation/kernel-hacking/hacking.rst:419-445

Memory and Stack Constraints

Architectures impose specific limits on memory and stack usage. Code must respect these limits to prevent system crashes and memory corruption.

Stack Limits

The kernel stack is rigid and varies by architecture:

• 32-bit architectures: Approximately 3K to 6K.
• 64-bit architectures: Approximately 14K.
  The stack is often shared with interrupts, requiring developers to avoid deep recursion and large local arrays.

Memory Alignment and Access

Architecture-specific implementations handle how memory is mapped. For example, vmalloc() provides contiguous virtual memory even if physical memory is fragmented, utilizing the architecture's MMU. Functions like copy_to_user() and copy_from_user() are used to bridge the gap between user space and kernel space memory, which may have different protection schemes depending on the CPU.

Sources: Documentation/kernel-hacking/hacking.rst:138-145, Documentation/kernel-hacking/hacking.rst:266-285

System Call Implementation

System calls are entry points into the kernel that require architecture-specific assembly in arch/kernel/entry.S and definitions in include/asm/unistd.h.

The sequence diagram illustrates the transition from user space to kernel space through architecture-specific entry code.
Sources: Documentation/kernel-hacking/hacking.rst:155-168

Summary of Architecture Management

Architecture-specific implementation is the foundation that allows the Linux kernel to run on diverse hardware. By isolating CPU-specific instructions, managing byte order, and providing atomic primitives, the kernel offers a stable environment for generic drivers and subsystems. Developers must adhere to portability rules, such as using __init for boot-only code and designated initializers for structures, to maintain code quality across all supported architectures.

Sources: Documentation/kernel-hacking/hacking.rst:147-152, Documentation/process/4.Coding.rst:146-150