1. Introduction

Linus B. Torvalds wrote the first Linux kernel in 1991. Linux gained in popularity because it has always been distributed as free software. Since the source code is readily available, users can freely change the kernel to suit their needs. However, it is important to understand how the Linux kernel has evolved and how it currently works before new system programs are written.

Operating System

Any computer system includes a basic set of programs called the operating system. The most important program in the set is called the kernel. The other programs are less crucial utilities; they can provide a wide variety of interactive experiences for the user as well as doing all the jobs the user bought the computer for but the kernel determines the essential shape and capabilities of the system.

Is kernel the entire operating system?

No, as discussed above. The kernel is the core component of the operating system. The operating system contains the Kernel plus other system utilities, which use the kernel to provide higher-level house keeping tasks. Technically speaking, Linux is only the kernel, as it does not provide system utilities like file system utilities, compilers, editors, and the graphical user interface that are provided by any other operating system. So Linux users typically rely on commercial distributions like Suse, Red Hat etc., to have the entire operating system. Having known what a Operating system and what the kernel is, let us know something about the history of the Linux kernel.More…
The Kernel and its Modules

Most kernels are compiled so modular support is required except many used on floppy boot disks.
The package modules.tar.gz contains all the programs needed to manage modules. This should already be installed on most distributions. The kernel modules are usually in a directory pertinent to the kernel version in /lib/modules. Modules can be found in “lib/modules/2.2.12-20″ for kernel version 2.2.12-20. They are loadable modules ending in “.o” that are used to support the kernel.
To load a module type “insmod module” where “module” is the name of the module to load.

Ex: insmod /lib/modules/2.2.12-20/misc/ftape.o

Programs used to manage modules are:

*

lsmod - Lists all the currently loaded kernel modules
*

rmmod - Unloads modules, Ex: rmmod ftape
*

depmod - Creates a dependency file, “modules.dep”, later used by modprobe to automatically load the relevant modules.
* modprobe - Used to load a module or set of modules. Loads all modules specified in the file “modules.dep”.

Modules are loaded from startup script files using “modprobe” to handle loadable modules automatically.

modprobe -l |more

Lists all the modules available for your kernel

rmmod module_name

Remove a module from the kernel
Finding the Kernel

Locate the kernel image on your hard disk. It should be in the file /vmlinuz, or /vmlinux. In some installations, /vmlinuz is a soft link to the actual kernel, so you may need to track down the kernel by following the links. On Redhat 6.1 it is in “/boot/vmlinuz”. To find the kernel being used look in “/etc/lilo.conf”.

Type “uname -a” to see the kernel version.

2. Features of the Linux Kernel

Monolithic kernel with module support

The Linux kernel is monolithic with module support. So now let us try to decipher the meaning of the previous sentence and why Linux adopted a monolithic kernel with module strategy.

Monolithic kernel
A monolithic kernel is a single large complex “do-it-yourself” kernel program, which is composed of several different logical entities (kernel layers). Each kernel layer is integrated in to the large kernel program and runs in kernel mode (more on kernel mode later) on behalf of the current process.

Microkernel

A micro kernel consists of a small set of important functions in the kernel generally a simple scheduler, synchronization primitives. Several System processes that run on top of the kernel to implement other OS layer functions like memory allocators, device drivers, system calls, file system etc., These kernel layers coordinate together by message passing between them. Thereby because of the message passing the microkernel is slower than the monolithic kernel.

Monolithic Vs Microkernel

Monolithic Kernel is faster than microkernel as stated above. However, Microkernel has some theoretical advantages over the monolithic kernel. They are as follows,

1.The microkernel occupies less RAM, since system processes (as discussed above) that are not doing their functionalities are swapped out or destroyed.

2.The architecture of the microkernel forces the programmers to adopt a modularized approach, as different layers of the kernel are independent of each other. Moreover, the different layers interact with each other through clear well defined software interfaces.

3.Moreover, an existing microkernel operating system can be fairly easily ported to other architectures, since all hardware dependent components are generally encapsulated in the microkernel code.

Modules, the Linux way

Modules are a kernel feature that effectively achieves many of the theoretical advantages of microkernels without introducing performance penalties. A module is an object file whose code can be linked to (and unlinked from) the kernel at runtime. The object code usually consists of a set of functions that implement a filesystem, a device driver, or other features at the kernel’s upper layer. The module, unlike the external layers of microkernel operating systems, does not run as a specific process. Instead, it is executed in Kernel Mode on behalf of the current process, like any other statically linked kernel function.

Advantages provided by a monolithic kernel with modules

1.Less main memory usage
A module is linked to the kernel when its functionality is needed and unlinked when its no longer used. This mechanism is done automatically by the kernel and is transparent to the user.

2.Modularized approach
Modules force the programmers to introduce well defined software interfaces for interaction.

3.Platform independence
A module does not depend on a fixed hardware platform. A module like device driver is infact specific to the device but not to the hardware platform (x86,sparc etc..,)

4.Faster
Since the module is linked in to the kernel, it is faster like the monolithic kernel as there is no message passing as in microkernel. Infact there is small time we lose for linking and unlinking of the modules which is less than that of the time required for message passing in microkernels.
3. System Architecture
3.1 System Overview

The Linux kernel is useless in isolation; it participates as one part in a larger system that, as a whole, is useful. As such, it makes sense to discuss the kernel in the context of the entire system. Figure 2.1 shows a decomposition of the entire Linux operating system:

!

The Linux operating system is composed of four major subsystems:

1.

User Applications — the set of applications in use on a particular Linux system will be different depending on what the computer system is used for, but typical examples include a word-processing application and a web-browser.
2.

O/S Services — these are services that are typically considered part of the operating system (a windowing system, command shell, etc.); also, the programming interface to the kernel (compiler tool and library) is included in this subsystem.
3.

Linux Kernel — this is the main area of interest in this paper; the kernel abstracts and mediates access to the hardware resources, including the CPU.
4. Hardware Controllers — this subsystem is comprised of all the possible physical devices in a Linux installation; for example, the CPU, memory hardware, hard disks, and network hardware are all members of this subsystem

Each subsystem layer can only communicate with the subsystem layers that are immediately adjacent to it. In addition, the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.

Since the primary interest of this paper is the Linux kernel, we will completely ignore the User Applications subsystem, and only consider the Hardware and O/S Services subsystems to the extent that they interface with the Linux kernel subsystem.

3.2 Purpose of the Kernel :The Linux kernel presents a virtual machine interface to user processes. Processes are written without needing any knowledge of what physical hardware is installed on a computer — the Linux kernel abstracts all hardware into a consistent virtual interface. In addition, Linux supports multi-tasking in a manner that is transparent to user processes: each process can act as though it is the only process on the computer, with exclusive use of main memory and other hardware resources. The kernel actually runs several processes concurrently, and is responsible for mediating access to hardware resources so that each process has fair access while inter-process security is maintained.
3.3 Overview of the Kernel Structure

The Linux kernel is composed of five main subsystems:

1.

The Process Scheduler (SCHED) is responsible for controlling process access to the CPU. The scheduler enforces a policy that ensures that processes will have fair access to the CPU, while ensuring that necessary hardware actions are performed by the kernel on time.
2.

The Memory Manager (MM) permits multiple process to securely share the machine’s main memory system. In addition, the memory manager supports virtual memory that allows Linux to support processes that use more memory than is available in the system. Unused memory is swapped out to persistent storage using the file system then swapped back in when it is needed.
3.

The Virtual File System (VFS) abstracts the details of the variety of hardware devices by presenting a common file interface to all devices. In addition, the VFS supports several file system formats that are compatible with other operating systems.
4.

The Network Interface (NET) provides access to several networking standards and a variety of network hardware.
5. The Inter-Process Communication (IPC) subsystem supports several mechanisms for process-to-process communication on a single Linux system.

Usually a subsystem will suspend a process that is waiting for a hardware operation to complete, and resume the process when the operation is finished. For example, when a process attempts to send a message across the network, the network interface may need to suspend the process until the hardware has completed sending the message successfully. After the message has been sent (or the hardware returns a failure), the network interface then resumes the process with a return code indicating the success or failure of the operation. The other subsystems (memory manager, virtual file system, and inter-process communication) all depend on the process scheduler for similar reasons.

The other dependencies are somewhat less obvious, but equally important:

*

The process-scheduler subsystem uses the memory manager to adjust the hardware memory map for a specific process when that process is resumed.
*

The inter-process communication subsystem depends on the memory manager to support a shared-memory communication mechanism. This mechanism allows two processes to access an area of common memory in addition to their usual private memory.
*

The virtual file system uses the network interface to support a network file system (NFS), and also uses the memory manager to provide a ramdisk device.
* The memory manager uses the virtual file system to support swapping; this is the only reason that the memory manager depends on the process scheduler. When a process accesses memory that is currently swapped out, the memory manager makes a request to the file system to fetch the memory from persistent storage, and suspends the process.

In addition to the dependencies that are shown explicitly, all subsystems in the kernel rely on some common resources that are not shown in any subsystem. These include procedures that all kernel subsystems use to allocate and free memory for the kernel’s use, procedures to print warning or error messages, and system debugging routines. These resources will not be referred to explicitly since they are assumed ubiquitously available and used within the kernel layer of Figure 3.1.

4. Conclusions

The Linux kernel is one layer in the architecture of the entire Linux system. The kernel is conceptually composed of five major subsystems: the process scheduler, the memory manager, the virtual file system, the network interface, and the inter-process communication interface. These subsystems interact with each other using function calls and shared data structures.

The conceptual architecture of the Linux kernel has proved its success; essential factors for this success were the provision for the organization of developers, and the provision for system extensibility. The Linux kernel architecture was required to support a large number of independent volunteer developers. This requirement suggested that the system portions that require the most development — the hardware device drivers and the file and network protocols — be implemented in an extensible fashion. The Linux architect chose to make these systems be extensible using a data abstraction technique: each hardware device driver is implemented as a separate module that supports a common interface. In this way, a single developer can add a new device driver, with minimal interaction required with other developers of the Linux kernel. The success of the kernel implementation by a large number of volunteer developers proves the correctness of this strategy.

Another important extension to the Linux kernel is the addition of more supported hardware platforms. The architecture of the system supports this extensibility by separating all hardware-specific code into distinct modules within each subsystem. In this way, a small group of developers can effect a port of the Linux kernel to a new hardware architecture by re-implementing only the machine-specific portions of the kernel.

Article Authored by Anish

Author, Anish, is a Sr.Systems Engineer(Team Lead) with SupportPRO. Anish specializes in Windows and Linux servers. SupportPRO offers 24X7 technical support services to Web hosting companies and service providers.