|
Memory Management and Linux
Linux uses a virtual memory-management system. The concept of virtual memory has been around since the early 1960s and is simple: the process sees its memory as a vector of bytes; and when the program reads or writes to memory, the processor, in conjunction with the operating system, translates the address into a physical address. The bit of the processor that performs this translation is the memory management unit (MMU). When a process requests memory, the CPU looks up the address in a table populated by the kernel to translate the requested address into a physical address. If the CPU can’t translate the address, it raises an interrupt and passes control to the operating system to resolve the address. The level of indirection supplied by the memory management means that if a process requests memory outside its bounds, the operating system gets a notification that it can handle or pass along to the offending process. In an environment without proper memory management, a process can read and write any physical address; this means memory-access errors may go unnoticed until some other part of the program fails because its memory has been corrupted by another process. Programs running in Linux do so in a virtual memory space.
That is, when a program runs, it has a certain address space that is a subset of the total system’s memory. That subset appears to start at 0. In reality, the operating system allocates a portion of memory and configures the processor so that the running program thinks address 0 is the start of memory, but the address is actually some arbitrary point in RAM. For embedded systems that use paging, this fiction continues: the kernel swaps some of the available RAM out to disk when not in use, a feature commonly called virtual memory. Many embedded systems don’t use virtual memory because no disk exists on the system; but for those that do, this feature sets Linux apart from other embedded operating systems.
Uniform Interface to Resources
This sounds ambiguous because there are so many different forms of resources. Consider the most common resource: the system’s memory. In all Linux systems, from an application perspective, memory from the heap is allocated using the malloc() function. For example, this bit of code allocates 100 bytes, storing the address to the first byte in from_the_heap:
char* from_the_heap; from_the_heap = (char*) malloc(100);
No matter what sort of underlying processor is running the code or how the processor accesses the memory, this code works (or fails in a predictable manner) on all Linux systems. If paged virtual memory is enabled (that is, some memory is stored on a physical device, like a hard drive) the operating system ensures that the requested addresses are in physical RAM when the process requests them. Memory management requires interplay between the operating system and the processor to work properly. Linux has been designed so that you can access memory in the same way on all supported processors. The same is true for accessing files: all you need to do is open a file descriptor and begin reading or writing. The kernel handles fetching or writing the bytes, and that operation is the same no matter what physical device is handling the bits:
FILE* file_handle; file_handle = fopen(“/proc/cpuinfo”, “r”);
Because Linux is based on the Unix operating system philosophy that “everything is a file,” the most common interface to system resource is through a file handle. The interface to that file handle is identical no matter how the underlying hardware implements this functionality. Even TCP connections can be represented with file semantics. The uniformity of access to resources lets you simulate a target environment on your development system, a process that once required special (and sometimes costly) software. For example, if the target device uses the USB subsystem, it has the same interface on the target as it does on the development machine. If you’re working on a device that shuffles data across the USB bus, that code can be developed, debugged, and tested on the development host, a process that’s much easier and faster than debugging code on a remote target.
System Calls
In addition to file semantics, the kernel also uses the idea of syscalls to expose functionality. Syscalls are a simple concept: when you’re working on the kernel and want to expose some functionality, you create an entry in a vector that points to an entry point of for the routine. The data from the application’s memory space is copied into the kernel’s memory space. All system calls for all processes are funneled through the same interface. When the kernel is finished with the syscall, it transfers the results back into the caller, returning the result into the application’s memory space. Using this interface, there’s no way for a program in user space to have access to data structures in the kernel. The kernel can also keep strict control over its data, eliminating any chance of data corruption caused by an errant caller.