Section 1.3. Kernel Overview

1.3. Kernel Overview

The purpose of any operating system is to provide an execution environment for applications, managing and allocating the underlying hardware resources such that applications get execution time on processors, have their active address space segments resident in physical memory, are able to do I/O to files and devices, and can communicate over a network. The operating system must be able to execute multiple applications, support multiple users, effectively manage a wide range of hardware platforms, and provide facilities for managing (controlling) and observing (troubleshooting, diagnosing) the workloads running on the system. We refer to the core operating system components and subsystems as the kernel.

The primary functions of the kernel can be divided into two major categories: managing the hardware by allocating its resources among the programs running on it; and supplying a set of system services for those programs to use. The Solaris kernel, like other operating systems, provides a virtual machine environment that shields programs from the underlying hardware and allows multiple programs to execute concurrently on the hardware platform. Each program has its own virtual machine environment, with an execution context and state.

The basic unit of a program's environment is known as a process; it contains a virtual memory environment that is insulated from other processes on the system. Each Solaris process can have one or more threads of execution that share the virtual memory environment of the process, and each thread in effect executes independently within the process's environment. Think of the process as an execution container for one or more threads. The Solaris kernel scheduler manages the execution of these threads (as opposed to management by scheduling processes) by transparently time-slicing them onto one or more processors. The threads of execution start and stop executing as they are moved on and off the processors, but the user program is unaware of this. Each time a thread is moved off a processor, its complete execution environment (program counter, stack pointers, registers, etc.) is saved, so when it is later rescheduled onto a processor, its environment can be restored and execution can resume.

Mechanisms in the kernel can access operating system services, such as file I/O, networking, process and thread creation and termination, process control and signaling, process memory management, resource control and management, and interprocess communication. A process accesses these kernel services through the use of system calls. System calls are programming interfaces through which the operating system is entered so that the kernel can perform work on behalf of the calling thread.

1.3.1. Solaris Kernel Architecture

The Solaris kernel is grouped into several key components and is implemented in a modular fashion:

• System call interface. The system call interface allows user processes to access kernel facilities. The kernel then performs specific tasks on behalf of the calling process, such as reading or writing a file, or establishing a network connection. The system call layer consists of a common system call handler, which vectors execution into the appropriate kernel modules.

• Process execution and scheduling. Process management facilities enable process creation, execution, management, and termination. The scheduler implements the functions that divide the machine's processor resources among threads on the system. The scheduler allows different scheduling classes to be loaded for different behavior and scheduling requirements.

• Memory management. The virtual memory system manages mapping of physical memory to user processes and the kernel. The Solaris memory management layer is divided into two layers: the common memory management functions and the hardware-specific components. The hardware-specific components are located in the hardware address translation (HAT) layer.

• Resource management. The Solaris kernel contains the infrastructure and administrative framework for allocating specific system resources (processor, memory, network) to applications. Resource management can maximize the use of system hardware, handle multiple workloads within a single kernel instance, and support multiple, virtualized, isolated execution environments within a single kernel instance.

• File systems. Solaris OS implements a virtual file system framework, by which multiple types of file system can be configured into the Solaris kernel at the same time. Regular disk-based file systems, network file systems, and pseudo file systems are implemented in the file system layer.

• I/O bus and device management. The Solaris I/O framework implements bus nexus node drivers (bus-specific architectural dependencies, for example, a PCI bus) and device drivers (a specific device on a bus, for example, an Ethernet card) as a hierarchy of modules, reflecting the physical layout of the bus/device interconnect.

• Kernel facilities (clocks, timers, etc.). Central kernel facilities include regular clock interrupts, system timers, synchronization primitives, and loadable module support.

• Networking. The Solaris networking subsystem provides complete IPv4 and IPv6 support, socket-based interfaces for network programming, and the traditional STREAMS framework for insertion of custom modules in the protocol stack. The TCP/IP and UDP/IP implementation in Solaris 10 has been completely rewritten for optimal performance and efficiency. The STREAMS connections between TCP and IP, and UDP and IP, has been removed and the code ore tightly integrated, leaving STREAMS in other areas of the networking infrastructure.

1.3.2. Modular Implementation

The Solaris kernel is implemented as a core set of operating system functions, with additional kernel subsystems and services linked in as dynamically loadable modules. This implementation is facilitated by a module loading and kernel runtime linker infrastructure, which allows kernel modules to be added to the operating system either during boot or on demand while the system is running.

The Solaris module framework supports seven types of loadable kernel modules: scheduling classes, file systems, loadable system calls, loaders for executable file formats, streams modules, bus or device drivers, and miscellaneous modules. Figure 1.1 shows the facilities contained in the core kernel and the various types of kernel modules that implement the remainder of the Solaris kernel.

Figure 1.1. Core Kernel and Loadable Modules