OS Architecture & Fundamentals

System Architecture & Resource Abstraction

An Operating System (OS) is low-level software that acts as an intermediary layer between physical hardware components (CPU, RAM, Disks, Network Adapters) and application processes.

Primary Responsibilities:

• Process Management: Allocates CPU time, schedules execution threads, and handles context switching.
• Memory Management: Maps virtual addresses to physical pages and enforces process isolation.
• File System Abstraction: Provides a unified hierarchical file access API (open, read, write) over block storage hardware.
• Device Management: Drivers abstract hardware-specific registers into generic I/O stream buffers.

# C System Call Interface Example
#include <unistd.h>
#include <fcntl.h>

int main() {
    // Low-level system call requesting OS to open file descriptor
    int fd = open("log.txt", O_WRONLY | O_CREAT, 0644);
    write(fd, "OS Architecture
", 16);
    close(fd);
    return 0;
}

OS Evolution & Deployment Topologies

Operating systems are engineered around specific workload constraints and execution guarantees:

1. Multiprogramming & Time-Sharing OS

• Keeps multiple processes in memory simultaneously. When one process waits for disk or network I/O, the CPU scheduler context-switches to another process, eliminating idle CPU cycles.

2. Real-Time OS (RTOS)

• Hard RTOS: Strictly enforces microsecond deadline guarantees. A missed deadline constitutes a catastrophic system failure (e.g., automotive braking, aerospace avionics).
• Soft RTOS: Prioritizes timeliness but tolerates rare latency spikes (e.g., video streaming playback).

3. Distributed OS

• Manages a collection of independent networked nodes, presenting them to application code as a single unified computing system (e.g., Kubernetes orchestration, Google Borg).

// Real-Time Periodic Task Scheduling (FreeRTOS)
void vPeriodicTask(void *pvParameters) {
    TickType_t xLastWakeTime = xTaskGetTickCount();
    const TickType_t xFrequency = pdMS_TO_TICKS(10); // 10ms hard deadline

    for (;;) {
        vTaskDelayUntil(&xLastWakeTime, xFrequency);
        // Execute critical sensor reading
        read_sensor_hardware();
    }
}

Dual-Mode Execution & Privilege Boundaries

Modern CPUs support hardware protection levels (User Mode vs Kernel Mode) to prevent untrusted application software from compromising system integrity.

Execution Control Flow:

1. User Mode (Ring 3): Applications execute with restricted CPU instructions and cannot directly touch hardware memory addresses.
2. Software Interrupt / Trap: When an application requires hardware operations, it executes a system call instruction (e.g., syscall on x86_64).
3. Kernel Mode (Ring 0): Hardware switches CPU privilege level to Ring 0, jumping directly to the pre-configured System Call Handler address in kernel space.

; Assembly System Call (Linux x86_64)
mov rax, 1          ; sys_write system call number
mov rdi, 1          ; stdout file descriptor
mov rsi, msg        ; pointer to buffer
mov rdx, 13         ; message length
syscall             ; Trigger privilege switch to Kernel Mode (Ring 0)

Monolithic vs Microkernel vs Hybrid

The Kernel is the foundational subsystem executing in privileged Ring 0 mode.

Architectural Trade-offs:

• Monolithic Kernel (e.g., Linux, BSD): File systems, networking stacks, and device drivers all run within kernel space. Advantage: Maximum execution speed (zero context-switching overhead for internal calls). Disadvantage: Driver crashes can panic the entire OS.
• Microkernel (e.g., QNX, seL4): Keeps only basic IPC, virtual memory, and thread scheduling in Ring 0. Drivers and file systems run as unprivileged user processes. Advantage: High isolation and fault tolerance. Disadvantage: Higher IPC overhead.
• Hybrid Kernel (e.g., Windows NT, macOS XNU): Runs drivers in kernel space for speed, but structures internal subsystems modularly like microkernels.

# Loading dynamic kernel modules in Linux Monolithic Kernel
sudo insmod custom_driver.ko
lsmod | grep custom_driver
sudo rmmod custom_driver

Hardware & Software Interrupts

An Interrupt is an asynchronous signal sent to the processor by hardware or software requiring immediate CPU attention.

Interrupt Execution Sequence:

1. Device sends interrupt request (IRQ) line signal to the Interrupt Controller (APIC).
2. CPU suspends execution of current instruction stream and pushes EFLAGS, CS, and EIP registers onto the kernel stack.
3. CPU indexes the Interrupt Vector Table (IVT) or IDT to locate the corresponding Interrupt Service Routine (ISR) address.
4. ISR runs, services device I/O buffer, acknowledges the interrupt, and executes IRET to restore user thread context.

// Low-Level C Interrupt Handler Structure
void __attribute__((interrupt)) keyboard_isr(void *frame) {
    uint8_t scancode = inb(0x60); // Read byte from Keyboard controller port
    process_scancode(scancode);
    outb(0x20, 0x20); // Send End of Interrupt (EOI) signal to PIC
}

From Power-On to Process PID 1

The OS boot process transitions physical hardware from uninitialized firmware state to user-space application execution:

Boot Sequence Steps:

1. Firmware Initialization (POST): Motherboard BIOS/UEFI executes Power-On Self Test and initializes DRAM registers.
2. Bootloader Stage (GRUB / Systemd-boot): Firmware reads First Sector (MBR) or EFI System Partition, loading the kernel binary (vmlinuz) and initial RAM disk (initrd) into memory.
3. Kernel Initialization: Kernel decompresses itself, initializes memory page tables, mounts initrd temporary root filesystem, and launches user space init process (PID 1 e.g., systemd).

# Inspecting PID 1 system process hierarchy in Linux
ps -p 1 -o comm,pid,ppid,args
pstree -p 1