Jun 2006

What is a Kernel?

An operating system kernel is the piece or pieces of software that is responsible for servicing resource requests from applications and the management of resources. A kernel has facilities to receive resource requests and grant access to resources such as allocating space for a new file or creating a network connection. To generalize, kernels use a system call (or syscall) interface to handshake with applications.

Figure kd1 is a basic sketch of how kernels communicate:

-----------
| request |
-----------
   |
-----------
| syscall |
-----------
   |
-----------
| kernel  |
-----------

figure kd1

Note that some kernels do not follow the exact system call method as will be seen later. A kernel may be thought of as a gate-keeper. When an application needs something it requires a set of hardware resources. The kernel is the middle-man between application and resources.

Why Have a Gate-keeper?

Except for single purpose operating systems, all modern operating systems are both multitasking and multiuser. In truth, no operating system (with the exception of some that are fully multiprocessor supporting) are actually performing more than one task at a time. The kernel employs a trick by sharing time at such a high speed, it appears that the computer is multitasking for multiple users. Because the system is sharing resources there must be a gate-keeper for two primary reasons:

• Facilitating timesharing.
• To make sure users do not violate other users' resources.

Timesharing is accomplished by context switching. In simple terms, context switching is:

• Current process context is saved out of the system registers.
• New process is copied in and performs operations in the alloted
time.
• Repeat ...

Conversely, the protection of user resources from other user resources is a broad and complex statement. When a new user process (or group of processes) start, the processes are allocated resources such as memory and disk space. Kernels have a variety of protection methods for system resources. Many kernels have differing protection methods yet some are similar because they share some sort of heritage.

Resource management

The kernel is also responsible for resource management. Resource management has several contexts:

• servicing requests from applications
• servicing systemic interrupts
• tracking/managing available resources

Servicing Requests from Applications

When any process requires resources, it must access the resource via the kernel indirectly. The kernel takes the request, performs the operation and returns the result. Upon initial examination, the idea of sending information back seems counterintuitive. Why not just hand over the resource? Sometimes a resource is just handed over.

An example of getting resources is a process has just started, it requires memory to reside in. The process makes the request and the kernel allocates the memory to the process itself. The kernel makes sure that the memory it is handing over to the process is not in use.

----------------------------
| new program instantiates |
----------------------------
            |
------------------------------------
|program requests space for itself |
------------------------------------
            |
----------------------------
| kernel allocates request |
----------------------------

fig kd2

An example of getting a return value is the sysctl utility; common on many systems. A process requests information about the kernel from the sysctl utility. The sysctl utility asks the kernel for the information and the result is returned to the process.

---------------------------------------------------
| process invokes sysctl utility with an argument |
---------------------------------------------------
                     |
---------------------------------------------------
| kernel receives the request via a syscall       |
---------------------------------------------------
                     |
---------------------------------------------------
| kernel fetches the variable information         |
---------------------------------------------------
                     |
---------------------------------------------------
| kernel sends information back to the caller     |
---------------------------------------------------

fig kd3

Servicing Systemic Interrupts

Computer systems have a set of interrupts both hardware and software based. Interrupts interrupt the current process because of a condition. An interrupt condition is often normal, when a mouse is moved it interrupts and the system is aware of the change in status.

Tracking and Managing Resources

Allocating and servicing requests is part of resource management. Kernels also do internal management that is not directly related to services. The kernel has to track what resources it is using and often collects information about various aspects of the system.

System Wide Resources and Transparency

Regardless of how kernels and entire systems are designed, all systems have a set of predefined resources to manage, allocate, protect and monitor. The highest level of grouping resources is:

• Long term Storage - hard drives, scsi arrays, tape devices...
• Processor - CPUs
• Short term storage - RAM plus virtual memory.
• General input and output - network interfaces, serial lines, connections to storage devices...

Systemwide resources are abstracted in the sense that the kernel recognizes what a device is and how to communicate with it at the lowest level, at the user level the device details are not apparent. A disk, known to the kernel at one level by model, size, type etc. is viewed from a high level (if allocated) through the perspective of the filesystem. The concept of abstraction is central to kernels for two reasons:

• Reinforcement of the UNIX metaphor
• The kernel should be transparent to its users

The UNIX metaphor is: everything is a file. In UNIX files are manipulated in a seemingly endless manner. The file metaphor is universal in UNIX and is the key to abstraction from a programming and user point of view.

The job of the kernel is to be as innocuous as possible. When a user asks for a resource they either get it or a reply (hopefully from the program) why the resource is not available. In other words, asking for things or information should be transparent and require no knowledge of the inner workings of the kernel itself.

Subsystems

Kernel software is generally organized into subsystems. Subsystems logically map to resources the kernel is dealing with. The Linux and NetBSD kernel source trees illustrate a file-to-subsystem mapping:

arch    
crypto  
drivers 
fs
init
ipc
kernel
lib
mm
net
security
sound

fig kd4 linux kernel

altq
arch
coda
compat
crypto
dev
dist
fs
ipkdb
kern
lib
lkm
miscfs
net
net80211
netatalk
netccitt
netinet
netinet6
netipsec
netisdn
netiso
netkey
netnatm
netns
netsmb
nfs
opencrypto
stand
sys
ufs
uvm

fig kd5 NetBSD Kernel

Note: Some files and supporting directories omitted for brevity.

The Magic of Layering

So far the idea of abstraction has been used to explain interaction between the kernel and processes. It is important that abstraction not be confused with the object oriented paradigms because most kernels do not employ a great deal of object oriented methods, at least not in the strictest sense. An easier way to think about how kernels abstract themselves is layering.

Filesystems sit at the center of the layering idea. Almost all subsystems have layering or frameworks. The details of both will be discussed later, but a good example is how filesystem layering works.

In the 4.4 BSD system the stackable filesystem idea was put forth. A stackable filesystem easily stacks interaction layers over lower level filesystems or drivers. Stackable filesystems are prevalent and make new filesystem design considerably easier. The concept of stackable filesystems is central to layering. In general terms a filesystem from the top down to an actual disk has many layers:

---------------------------------------------------
|user interface to filesystem                     |
---------------------------------------------------
                        |
---------------------------------------------------
|filesystem interface to the kernel               |
---------------------------------------------------
                        |
---------------------------------------------------
|kernel generic filesystem layer and functions    |
---------------------------------------------------
                        |
---------------------------------------------------
|stub to device drivers and disk layout structures|
---------------------------------------------------
                        |
---------------------------------------------------
|device driver                                    |
---------------------------------------------------
                        |
---------------------------------------------------
|device media                                     |
---------------------------------------------------

fig kd5 example filesystem layers

Fig kd5 is oversimplified but it follows the basic premise of how kernel subsystems work.

Summary

A kernel manages resources for a several reasons such as servicing resource requests, tracking and management. The kernel is designed in such a way as it is transparent to users, programs and processes that it handshakes with.

Nest up, how kernel designs fit into categories and what that means...

Last modified: June 10 2006 04:28:42 by jay.fink@gmail.com

Full Story