Entering the kernel


Once the machine is booted , there are only two ways in which the kernel code will be run: if a user makes a system call or if a device requests attention. These might be considered as the only two entrances into the kernel. A large portion of the kernel is devoted to handling user requests. This involves identifying the system call, validating the parameters, and heading off to the right area of the kernel to do the real work. The other entrance (from hardware signals) is via the device drivers, which handle the specific details about controlling various devices. One of these devices may in fact be the clock, which " ticks " every 100 milliseconds on Sun systems. This is also one way in which the scheduler gets invoked; if enough time has elapsed, the current user process may be suspended to allow another one to get some work done.

The following figure presents a fairly broad overview of the kernel and its component parts . The system call handling is one way ” the only way ” for user processes to get the kernel to do work for them. At the other end, devices can request attention through a device driver, which may involve other pieces of the kernel as well.

Figure 19-1. Kernel Overview

graphics/19fig01.gif

Let's move back to system calls. From a system programmer's standpoint, these requests look almost like a subroutine call to a kernel-level function. In actuality, the user program will issue a "software trap" instruction of some sort (dependent on the type of hardware) and will end up transferring control to the kernel temporarily in order to handle the system request. These system calls are the only way the user can access those facilities that are tightly controlled by the kernel. These normally include all the hardware (tapes, terminals, disks, etc.), memory, and any other user programs, plus software facilities such as IPC and pseudo-devices .

System calls exist to manipulate files ( open , close , read , write ), devices ( ioctl ), memory ( mmap , sbrk ), other processes (signals, IPC, fork , exec ), and the process's own environment (resource limits, priority, current directory). Every UNIX user program and utility does its work by using the appropriate system calls to find and manipulate the proper data.

Kernel system call handling generally goes through these basic steps:

  • Enter the system, identify the system call (verify that this is a legal request), and branch to the right system call handler.

  • Validate parameters (Is the file open? Is this process allowed to access this data? Is the buffer address legal and mapped in?)

  • Do the work, which may involve devices, network accesses , or other processes.

  • Return any error conditions to the user as a special numeric code.

Error return values are placed inside a special variable in the U-area (the user structure) or the thread structure, each of which contains per-process information needed by the kernel. Any error is returned as the result of the system call, along with an error flag to distinguish error codes from legitimate return values. The flag is the carry-bit in the processor status register ( PSR ) for SPARC systems. Error values are placed by the system call code in libc into the global variable errno , which is actually resident in libc itself.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net