Linux Overview

01 Introduction

Everything you will do in the laboratories and programming assignments of this course runs on Linux. It is the operating system that has shaped modern computing more than any other: it runs the majority of servers on the internet, every Android phone, every one of the top 500 supercomputers, and — through derivatives and inspiration — it influences macOS, Windows Subsystem for Linux, and every container in the cloud.

Linux is worth studying for two reasons. First, it is a real, production operating system, not a teaching abstraction. Every mechanism the course discusses — process scheduling, virtual memory, file systems, device drivers, networking — is implemented in a codebase you can read, build, and modify. Second, its design is exemplary: a monolithic kernel with loadable modules, strict separation between kernel and user space, and a portability discipline that has allowed it to run on virtually every hardware architecture ever designed.

This lesson introduces Linux from the outside in: what it is, how it is organised, what the kernel does, and how the open-source development model has produced and maintained it. The following four lessons in this unit will give you the skills to work with it directly.

02 Learning objectives

This lesson contributes to U2.1 and to course learning outcomes CLO1 and CLO6.

03 Required reading

• Love, R. — Linux Kernel Development, 3rd ed., Chapter 1: Introduction to the Linux Kernel. A concise, authoritative overview of kernel architecture.
• Stevens & Rago — Advanced Programming in the UNIX Environment, 3rd ed., Chapter 1: UNIX System Overview. The classical UNIX worldview, from which Linux inherits.
• Linux kernel documentation — Documentation/process/, especially development-process.rst and submitting-patches.rst.
• Linux man pages: man 1 intro, man 2 intro, man 7 intro. These give a quick tour of user commands, system calls, and conventions.

04 Core content

4.1 What Linux is — and is not

Colloquially, "Linux" refers to a whole family of operating systems: Ubuntu, Fedora, Debian, Red Hat Enterprise Linux, Arch, Alpine, and hundreds of others. Strictly speaking, that family is more precisely called GNU/Linux, because it is the combination of two historically separate projects:

• Linux — the kernel, started by Linus Torvalds in 1991, which manages hardware and provides the fundamental abstractions of process, file, socket, and memory.
• GNU — a project started by Richard Stallman in 1983 to produce a free replacement for the UNIX operating system. By 1991 the GNU project had produced almost every user-space component of a complete OS — the C library, the shell, the compiler, the core utilities — but its own kernel (Hurd) was not finished.

The combination of the GNU user space with the Linux kernel produced a complete, free operating system. This is why you will see both terms used, and why purists insist on "GNU/Linux" — but "Linux" alone is the common usage and the one we will use throughout the course.

4.2 Linux architecture

Linux follows the classical UNIX architecture, with a strict separation between two worlds: user space, where applications run, and kernel space, where the operating system itself runs.

4.3 Kernel responsibilities

The kernel is the software that runs in privileged mode and manages the machine's resources. Concretely, it is responsible for:

Process management

Creating, scheduling, suspending, and terminating processes and threads; providing inter-process communication and synchronisation mechanisms.

Memory management

Giving each process an isolated virtual address space; translating virtual addresses to physical frames via the MMU; managing page allocation, page replacement, and swapping.

File-system management

Providing a uniform abstraction over diverse storage devices and file-system formats; managing directories, permissions, file descriptors, and caches.

Device management

Interfacing with hardware through drivers; handling interrupts and DMA; presenting a uniform device interface to user space.

Networking

Implementing protocols (TCP/IP, UDP, UNIX sockets); routing packets; enforcing firewall rules; providing the socket API.

Security and protection

Enforcing user and group permissions, capabilities, mandatory access control policies, and the isolation between processes.

4.4 Linux kernel subsystems

The Linux kernel is organised into several major subsystems, each with its own responsibilities and internal interfaces. The subsystems you will encounter most in this course are:

4.5 Monolithic with modules

Linux is a monolithic kernel: all of these subsystems run in a single address space in kernel mode, and they call one another directly as ordinary functions. This contrasts with microkernel designs, where subsystems run as separate user-space services.

The advantage of monolithic design is performance: an operation that crosses subsystem boundaries is a function call, not an IPC round trip. The disadvantage is fragility: a bug in any subsystem can corrupt kernel memory and crash the system.

Linux mitigates the fragility with loadable kernel modules (LKMs). A module is kernel code that can be inserted into and removed from a running kernel on demand — usually a device driver or a file-system implementation. Modules preserve the performance advantage of monolithic design (they run in kernel mode and share the kernel's address space) while allowing the kernel to remain small and modular.

# List currently loaded modules
$ lsmod | head -5
Module                  Size  Used by
nls_iso8859_1          16384  1
nls_cp437              20480  1
vfat                   24576  1

# Show metadata about a specific module
$ modinfo e1000e | head -6
filename:       /lib/modules/.../kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        3.2.6-k
license:        GPL
description:    Intel(R) PRO/1000 PCI-Express Network Driver
author:         Intel Corporation
srcversion:     ...

4.6 Kernel and user space

The boundary between kernel space and user space is enforced by the CPU's privilege modes. On x86-64, kernel code runs in ring 0 (the most privileged) and user code in ring 3. When a user-space program wants a service that only the kernel can provide — opening a file, creating a process, sending a packet — it issues a system call: a controlled trap into the kernel.

System calls are the only legitimate way for user code to reach kernel services. There are roughly 350 of them on modern Linux, grouped by category:

• Process control. fork, execve, exit, wait4, clone.
• File operations. openat, read, write, close, stat, mmap.
• Memory management. brk, mmap, mprotect, madvise.
• Communication. pipe, socket, sendto, recvfrom.
• Information. getpid, uname, time, getrlimit.
• Protection. chmod, chown, setuid, capset.

This interface is stable across kernel versions — an important property, because applications compiled years ago continue to work on today's kernels. The Linux kernel's developers are famously strict about never breaking the system-call interface.

4.7 The open-source development model

Linux is not developed by a single company or a single team. It is the largest collaborative software project in history:

• Scale. Roughly 30 million lines of code, with contributions from over 20,000 developers across more than 1,500 companies.
• Cadence. A new major release approximately every 9–10 weeks. Each release incorporates thousands of patches from hundreds of contributors.
• Licensing. Released under the GNU General Public License version 2 (GPLv2), which requires that derivative works also be released under the same license. This is why Linux cannot be made proprietary, and why companies that modify it must publish their changes.
• Governance. A hierarchical, trust-based structure. Contributors submit patches to subsystem maintainers, who review them and forward accepted work to Linus Torvalds, who makes the final decision for each release.

This model has practical consequences for anyone working with Linux:

• You can read the source. Every subsystem this course discusses is available at kernel.org and mirrored on GitHub. When the textbooks describe a mechanism, you can see how it actually works.
• You can build your own kernel. Compiling a custom kernel — with only the drivers and features you need — is a standard operation and part of the Lab 1 workflow.
• You can contribute. The process is documented in Documentation/process/ and is open to anyone, regardless of employment. First-time contributors are welcomed and mentored.
• Distributions matter. Because the kernel is just one piece, a Linux distribution bundles the kernel with a user space, package manager, init system, and policy choices — which is why Ubuntu, Fedora, and Debian feel different even though they share a kernel.

4.8 Linux and UNIX

Linux is not UNIX. UNIX is a trademarked operating system originally developed at AT&T Bell Labs in the 1970s; today the trademark is held by The Open Group, and systems that meet its specification can be certified as "UNIX". Linux has never been certified, and the name is deliberately different: "Linux Is Not UniX".

What Linux shares with UNIX is far more important than the branding:

4.9 Practical consequences for this course

Two consequences follow directly from what we have covered, and they will shape everything you do in the laboratories:

1. You will work in user space, using system calls. Every program you write for this course — the process management labs, the threading labs, the file-system labs — will be a user-space program that requests services through the system-call interface. This is the natural place to observe the OS's behaviour.
2. You can inspect the kernel when you need to. The /proc and /sys pseudo-filesystems, the strace and perf tools, and the source code itself are all available. When the textbook says "the scheduler picks the process with the smallest virtual runtime", you can open kernel/sched/fair.c and read the implementation.

The next four lessons in this unit will give you the tools to work with Linux effectively: the shell, users and groups, permissions, and the development environment. Every subsequent laboratory in the course assumes the skills you will build there.

05 Worked example

To make the architecture concrete, trace what happens when a simple user-space program asks the kernel for a service.

#include <unistd.h>
#include <stdio.h>

int main(void) {
    /* Both of these lines cross the system-call interface */
    write(STDOUT_FILENO, "hello\n", 6);
    pid_t me = getpid();
    printf("my pid is %d\n", me);
    return 0;
}

$ strace -e trace=write,getpid,exit_group ./hello
write(1, "hello\n", 6)                 = 6
getpid()                              = 12345
write(1, "my pid is 12345\n", 17)      = 17
exit_group(0)                         = ?
+++ exited with 0 +++

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• Linux, strictly speaking, is the kernel; the complete operating system is GNU/Linux — the kernel paired with a user space. In common usage, "Linux" refers to the whole family of distributions.
• Linux follows the classical UNIX architecture: a strict separation between user space and kernel space, with the system-call interface as the boundary between them.
• The kernel is responsible for process management, memory management, file systems, device management, networking, and security.
• The main kernel subsystems are the process scheduler, memory manager, virtual file system, network stack, device drivers, and security framework.
• Linux is a monolithic kernel with loadable modules: all subsystems run in one address space for performance, and modules can be inserted or removed at runtime for flexibility.
• Linux is developed as an open-source project under the GPLv2, with contributions from thousands of developers across many companies. You can read, build, and modify the source.
• Linux is not certified UNIX, but it implements POSIX, which is what determines whether a program is portable across UNIX-like systems.

11 References

• Love, R. Linux Kernel Development, 3rd ed., Chapter 1. Addison-Wesley, 2010.
• Stevens, W. R., & Rago, S. A. Advanced Programming in the UNIX Environment, 3rd ed., Chapter 1. Addison-Wesley, 2013.
• Torvalds, L., & Diamond, D. Just for Fun: The Story of an Accidental Revolutionary. HarperCollins, 2001. (Historical account of Linux's origins.)
• Linux kernel source: https://kernel.org and https://github.com/torvalds/linux.
• Linux kernel documentation: Documentation/process/.
• POSIX.1-2017 / IEEE Std 1003.1, Standard for Information Technology — Portable Operating System Interface (POSIX).