SMP, Kernel Preemption, and High Memory

It might seem somewhat incorrect to include symmetrical multiprocessing, kernel preemption, and high memory in a discussion of portability. After all, these are not machine characteristics that affect an operating system, but instead they are features of the Linux kernel that are indeed somewhat architecture-agnostic. They represent, however, important configuration options that you should always assume are available in your code. That is, always program for an SMP/preempt/highmem system and you will always be safe, in any configuration. In addition to the previous portability rules, you need to follow these as well:

• Always assume your code will run on an SMP system and use appropriate locking.

• Always assume your code will run with kernel preemption enabled and use appropriate locking and kernel preemption statements.

• Always assume your code will run on a system with high memory (non- permanently mapped memory) and use kmap() as needed.

Portability Is Fun

In short, writing portable, clean, proper code has two major implications:

• Always code for the highest common factor: Assume anything can happen and any potential constraint is in place.

• Always assume that only the lowest common denominator is available: Do not assume any given kernel feature is available and require only the minimum architectural features.

Writing portable code requires awareness of many issues, including wordsize, data type size, alignment, byte order, page size, processor ordering. In the large majority of kernel programming, the primary concern is only ensuring that data types are used correctly. Nonetheless, one day an archaic architecture issue will arise, so it is important to understand portability issues and always write clean, portable code inside the kernel.