The kernel is the part of the operating system that has the authority to control the machine.

Applications cannot freely choose physical memory, issue commands to storage devices, or take permanent control of a CPU core. They ask the kernel to perform protected operations on their behalf.

This arrangement gives the kernel two closely related jobs:

The kernel therefore does much more than provide a collection of unrelated services. It maintains a coordinated view of the entire running system.

The kernel runs with the privilege needed to configure the processor, manage memory, and communicate with devices.

Applications run with fewer privileges. When an application needs a protected operation, it crosses a controlled boundary and requests that operation from the kernel. The exact request mechanism will be covered in the system-calls chapter.

At a high level, the system looks like this:

The five responsibilities inside the kernel are not isolated. Reading a file, receiving a network request, and starting a program each involve several of them.

The exact boundary between kernel code and other operating-system components varies among kernel designs. For now, the important idea is that the kernel is the privileged coordinator for the machine's core resources.

Across its different responsibilities, the kernel repeatedly performs three kinds of work.

Abstraction

Hardware exposes low-level mechanisms. A storage device reads and writes blocks, a network interface sends and receives frames, and the processor executes instructions.

The kernel turns those mechanisms into objects that applications can use more easily:

These abstractions are not just convenient names. The kernel stores information about each object, tracks its current state, and defines which operations are valid.

Allocation and sharing

Resources are limited. Several programs may want CPU time, memory, storage access, or network capacity simultaneously.

The kernel decides which requests can be satisfied immediately, which must wait, and how much of a resource each program may use. It also records who owns or is currently using each resource.

Protection

Sharing would be unsafe without boundaries.

The kernel checks whether a program is allowed to access a resource. It prevents one process from directly reading another process's private memory, restricts access to files, and controls privileged device operations.

These checks depend on kernel-maintained identities, ownership information, and permissions. A program cannot safely enforce these rules by itself because an untrusted program could simply remove its own checks.

A program stored in a file is passive. To run it, the kernel creates and manages a process.

The process gives the kernel a unit to track. For each process, the kernel maintains information such as:

This information lets the kernel stop one process, run another, and eventually resume the first. It also lets the kernel reclaim the process's resources when the process exits.

On a machine with many runnable programs and only a few CPU cores, not everything can execute at once. The kernel chooses which process can use each core at a given moment.

Four runnable processes and two cores means two of them wait, and the kernel decides which. Timer interrupts ensure that the kernel regularly regains control of a CPU. The policies and mechanisms used to choose the next process belong to the later CPU-scheduling module.

For this chapter, the key point is that the kernel connects execution to ownership. CPU time is given to a process whose memory, open resources, and permissions the kernel already knows.

Programs need memory for their instructions, variables, stacks, and dynamically allocated data.

The kernel tracks physical memory and decides how it is used. Some memory belongs to the kernel itself, some is assigned to running processes, and some may hold recently accessed file data.

Each process normally works within its own address space. An address used by one process does not automatically refer to the same physical location as that address in another process.

Both processes can use the same address and still reach different physical memory, because every access passes through the mappings the kernel controls. This separation improves both reliability and security. A bad pointer in one process should not give that process unrestricted access to another process's data.

Memory management is also connected to files and devices. The kernel can keep file data in memory so repeated reads avoid slower storage. Devices may transfer data through memory buffers. When memory becomes scarce, the kernel must decide how to use the available space.

Later modules will explain address translation, paging, page faults, allocation, and replacement policies. At this stage, remember that the kernel maintains the mappings and ownership information that make isolated process memory possible.

Storage devices expose numbered blocks of data. Applications usually want named, persistent information such as:

The kernel, together with its filesystem implementations, presents storage as files and directories.

It tracks file names, locations, sizes, ownership, permissions, and other metadata. When a process opens a file, the kernel also records that the process has an active reference to it and keeps track of information needed for later operations.

Suppose two processes read the same file:

Two independent readers meet at a single piece of kernel state. The kernel coordinates their access and may satisfy both reads from one in-memory copy of the file data.

Writing introduces more coordination. The kernel may temporarily buffer modified data in memory before sending it to a storage device. It must also enforce access permissions and preserve the filesystem's internal consistency.

The data structures and algorithms that organize files on disk will be covered in the filesystem and storage modules. The important architectural point is that applications use stable file operations while the kernel handles naming, protection, caching, and device-specific I/O underneath.

Keyboards, displays, storage drives, audio devices, and network cards have different command formats and hardware behavior.

The kernel communicates with them through device drivers. A driver understands a particular device or family of devices and connects it to the rest of the kernel.

A request travels down four levels: the application makes the request, the kernel's common interface receives it, the device driver translates it, and the hardware device carries it out.

This separation prevents every application from needing hardware-specific code. The same file-reading program can work with data stored on different models of drive because the kernel and drivers handle the differences.

The kernel also coordinates shared device access. If multiple programs send data to one storage device, the kernel and its driver arrange those requests rather than allowing the programs to issue conflicting hardware commands.

Devices often operate much more slowly than the CPU. Instead of making a process occupy the CPU while it waits, the kernel can record the pending operation and let other work run. When the device finishes, it can notify the CPU with an interrupt. The kernel then updates the operation's state and makes the result available to the waiting process.

The detailed I/O path, buffering strategies, and driver behavior belong to the later I/O module.

Applications should not need to construct hardware commands for a particular network card or independently coordinate access to it.

The kernel provides networking abstractions, commonly sockets, that applications use to communicate. It maintains the state of connections, moves data through network buffers, applies protocol rules, and directs incoming data to the correct process.

A simplified receive path looks like this:

Many programs can use the network at once. The kernel keeps their communication separate even though the packets ultimately pass through the same physical network interface.

The kernel also enforces rules that require a system-wide view. For example, it tracks which local network endpoints are already in use and applies configured routing and filtering decisions.

Networking is closely tied to process and memory management. Received data waits in kernel-managed memory until the destination process can handle it. If that process is not currently running, the kernel may mark it ready to run when data becomes available.

Consider a backend server handling a request for a file.

This one request involves process management, CPU allocation, memory, files, a storage driver, and networking.

It also demonstrates why the kernel needs shared bookkeeping. The kernel must know which process owns the connection, whether that process may read the file, where the relevant data is in memory, and which device should receive the outgoing bytes.

Real systems optimize this path heavily, and not every request follows every step. The file may already be cached in memory, for example, so no storage operation is necessary. The diagram is a responsibility map rather than an exact execution trace.

The kernel maintains data structures describing processes and resources across the entire machine.

This system-wide view lets it answer questions that a single application cannot:

The kernel must update related state carefully. If a process exits, for example, the task is not merely to stop executing its instructions. The kernel must also release or transfer the resources associated with it: memory, file references, pending operations, and network connections.

This cleanup is possible because the kernel has tracked those relationships throughout the process's lifetime.

Not every part of an operating system runs inside the kernel.

Shells, graphical desktops, compilers, many background services, and most system libraries normally run as ordinary user-space programs. They may provide important operating-system functionality, but they use kernel services rather than directly controlling protected hardware.

For example, a shell can start a program, but it asks the kernel to create and manage the resulting process. A logging service can organize application logs, but it relies on the kernel to write the underlying files.

Keeping functionality outside the kernel limits how much code runs with unrestricted privilege. The precise division between kernel and user space depends on the operating system's architecture, which is the subject of the next chapter.

Linux exposes views of kernel state through tools and virtual filesystems such as /proc.

To see processes currently known to the kernel, run:

To view a summary of memory use, run:

To list storage devices, run:

To display network-interface statistics, run:

These commands show different parts of one system-wide resource model. Their output changes as processes start and stop, memory is allocated and released, files are accessed, and network traffic arrives.

The tools do not manage those resources themselves. They ask the kernel for a view of the state it already maintains.

The kernel is the privileged core of the operating system. It turns hardware into usable abstractions, shares limited resources, and enforces protection boundaries.

Its central responsibilities include managing processes and CPU time, memory, files, devices, and networking. These areas constantly interact: even one backend request can involve all of them.

A useful mental model is:

The kernel maintains the machine's shared state and coordinates every protected resource on behalf of applications.