What is a Kernel?
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:
Timesharing is accomplished by context switching. In simple terms, context switching is:
time. 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 managementThe kernel is also responsible for resource management. Resource management has several contexts:
Servicing Requests from ApplicationsWhen 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.
---------------------------- | 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 InterruptsComputer 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
System Wide Resources and TransparencyRegardless 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:
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:
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. SubsystemsKernel 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 LayeringSo 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:
fig kd5 example filesystem layers Fig kd5 is oversimplified but it follows the basic premise of how kernel subsystems work. SummaryA 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...
|
|
This topic does not have any threads posted yet!
You cannot post until you login.