Here are some fundamental facts about the Linux kernel. Notice that the name "Linux" is a trademark registered to Linus Torvalds [2].  The original articles (references below) were so good that I wanted to make a shortnote from the readings to keep them more concise and organized in my way for the future use. Most of the info come from the first article. So, if you get confused, please go to the original.  Please feel free to make any comment.

  1. core of a large and complex operating system (over six million lines of code--wikipedia says 2.4 million?).
  2. well organized in terms of subsystems and layers.
  3. written to be compiled with GCC.
  4. History
    • Linus Torvald, as a student in 1991, started developing 32-bit Linux kernel, after the 16-bit open source operating system created by Andrew Tanenbaum  in 1987 (MINIX for minimal UNIX; the microkernel version of UNIX® ran on small personal computers).
    • Source lines of code have increased from 10,239 in Kernel release 0.11 (Dec 91) to 5,929,913 in Kernel release 2.6.0 (Dec 03).
  5. under GNU General Public License (GPL). 
  6. The OS is called "GNU/Linux" because it uses many GNU software (the applications include windowing system, compiler/GNU Compiler Collection (GCC), variety of shells, development tools, editors, utilities, and other applications exist outside of the kernel) (Linux referred to the kernel)
  7. Architecture of GNU/Linux OS 
    1. Two levels (see the interactions in the Fig.) on the hardware platform.
      1. User/Application space
        • User Applications
        • GNU C Library (glibc)
      2. Kernel space
        • System Call Interface (SCI)
        • Kernel
        • Architecture-Dependent Kernel Code
    2. Functions of each component.
      1. glibc
        • provides SCI
        • provides mechanism to transition between the user-space application and the kernel (over the different protected address spaces)
      2. SCI
        • a thin layer that provides the means to perform function calls from user space into the kernel (is actually an interesting function-call multiplexing and demultiplexing service.)
        • architecture dependent, even within the same processor family (use different mechanism in different CPUs).
        • implements the basic functions such as read and write. 
        • the SCI implementation is in ./linux/kernel, as well as architecture-dependent portions in ./linux/arch.
      3. Kernel code (architecture-independent kernel code) 
        • common to all of the processor architectures supported by Linux. 
        • a resource manager.
          • manages and arbitrates access to the resource between multiple competing users (both in the kernel and in user space).
      4. Architecture-dependent kernel code
        • forms Board Support Package (BSP). 
        • serves as the processor and platform-specific code for the given architecture.
  8. Properties
    • implements a number of important architectural attributes. 
    • layered into a number of distinct subsystems. 
    • it lumps all of the basic services into the kernel (monolithic type). 
    • This differs from a microkernel architecture where the kernel provides basic services such as communication, I/O, and memory and process management, and more specific services are plugged in to the microkernel layer. (However, each has its own advantages.)
    • efficient in terms of both memory and CPU usage
    • extremely stable. 
    • portability.
      • can be compiled to run on a huge number of processors and platforms with different architectural constraints and needs, such as running on a process with/without a memory management unit (MMU).
  9. Major Subsystems
    1. system call interface (SCI): see above.
    2. process management (PM)
      • focused on the execution of processes. 
        • In the kernel, these are called threads and represent an individual virtualization of the processor (thread code, data, stack, and CPU registers). 
        • In user space, the term process is typically used, though the Linux implementation does not separate the two concepts (processes and threads). 
      • The kernel provides an application program interface (API) through the SCI to
        • create a new process (fork, exec, or Portable Operating System Interface [POSIX] functions)
        • stop a process (kill, exit), and 
        • communicate and synchronize between them (signal, or POSIX mechanism).
      • the need to share the CPU between the active threads.
        • The kernel implements a novel scheduling algorithm (O(1) scheduler)
        • operates in constant time, regardless of the number of threads vying for the CPU. (same amount of time is taken to schedule one thread as it is to schedule many.) 
        • also supports multiple processors (called Symmetric MultiProcessing, or SMP). 
      • sources in ./linux/kernel and architecture-dependent sources in ./linux/arch
    3. memory management (MM)
      • the hardware manages virtual memory
      • memory is managed in pages (4KB in size for most architectures). 
      • manage the available memory, as well as the hardware mechanisms for physical and virtual mappings.
      • with the slab allocator, this memory management scheme uses 4KB buffers as its base, but then allocates structures from within, keeping track of which pages are full, partially used, and empty. This allows the scheme to dynamically grow and shrink based on the needs of the greater system.
      • Supporting multiple users of memory, there are times when the available memory can be exhausted. For this reason, pages can be moved out of memory and onto the disk. This process is called swapping because the pages are swapped from memory onto the hard disk. 
      • sources in ./linux/mm
    4. virtual file system (VFS)
      • provides a common interface abstraction for file systems. 
      • provides a switching layer between the SCI and the file systems supported by the kernel
      • At the top: a common API abstraction of functions such as open, close, read, and write.
      • At the bottom: the file system abstractions that define how the upper-layer functions are implemented. These are plug-ins for the given file system (of which over 50 exist). 
      • sources in ./linux/fs.
      • Below the file system layer is
        • the buffer cache
        • provides a common set of functions to the file system layer (independent of any particular file system).
        • optimizes access to the physical devices by keeping data around for a short time (or speculatively read ahead so that the data is available when needed).
      • Below the buffer cache are the device drivers (see below).
    5. network stack
      • follows a layered architecture modeled after the protocols themselves. Recall that the Internet Protocol (IP) is the core network layer protocol that sits below the transport protocol (most commonly the Transmission Control Protocol, or TCP). Above TCP is the sockets layer, which is invoked through the SCI.
      • The sockets layer is the standard API to the networking subsystem and provides a user interface to a variety of networking protocols. From raw frame access to IP protocol data units (PDUs) and up to TCP and the User Datagram Protocol (UDP), the sockets layer provides a standardized way to manage connections and move data between endpoints. 
      • sources in ./linux/net.
    6. device drivers (DD)
      • The vast majority of the source code in the Linux kernel exists in device drivers that make a particular hardware device usable. 
      • implement the interface for the particular physical device.
      • The Linux source tree provides a drivers subdirectory that is further divided by the various devices that are supported, such as Bluetooth, I2C, serial, etc. 
      • sources in ./linux/drivers.
    7. architecture-dependent code
      • some elements must consider the architecture for normal operation and for efficiency. 
      • a number of subdirectories that are specific to the architecture (collectively forming the BSP). 
      • For a typical desktop, the i386 directory is used. Each architecture subdirectory contains a number of other subdirectories that focus on a particular aspect of the kernel, such as boot, kernel, memory management, and others. 
      • Sources in ./linux/arch
  10. Interesting features
    • portability and efficiency
    • a great test bed for new protocols and advancements of those protocols. 
    • supports a large number of networking protocols, including the typical TCP/IP, and also extension for high-speed networking (greater than 1 Gigabit Ethernet [GbE] and 10 GbE). 
    • supports protocols such as the Stream Control Transmission Protocol (SCTP), which provides many advanced features above TCP (as a replacement transport level protocol).
    • a dynamic kernel, supporting the addition and removal of software components on the fly. These are called dynamically loadable kernel modules, and they can be inserted at boot when they're needed (when a particular device is found requiring the module) or at any time by the user.
    • used as an operating system for other operating systems (called a hypervisor). 
    • a modification, the Kernel-based Virtual Machine (KVM), enabled a new interface to user space that allows other operating systems to run above the KVM-enabled kernel. 
    • Compatibility, can run some Microsoft programs

References
1. Jones, M.T. (June 06, 2007) Anatomy of the Linux kernel. available from http://www.ibm.com/developerworks/linux/library/l-linux-kernel/, accessed Dec.19, 2008.
2. Wikipedia; Linux available from http://en.wikipedia.org/wiki/Linux accessed Dec.19, 2008.
images