Part 1: OS Fundamentals, Kernel & System Calls

1. Program vs. Process vs. Thread

To understand the OS, you must understand the transition from static code to active execution.

• Program (Static/Passive): An executable file stored on the disk (e.g., browser.exe or main.py). It is a sequence of instructions, but it does nothing until loaded into memory.

• Process (Active/Dynamic): An instance of a program in execution. The OS creates a Process Control Block (PCB) for it, containing:

• Process State: (New, Ready, Running, Waiting, Terminated).

• Program Counter: Address of the next instruction to execute.

• CPU Registers & Stack: Temporary data and local variables.

• Memory Management Info: Page tables or segment tables.

• Thread (Lightweight Process): A thread is the smallest unit of CPU utilization within a process.

• The “Why”: Processes are heavy because they require their own memory space and OS overhead to create. Threads within the same process share the code section, data section, and open files.

• Efficiency: Context switching between threads of the same process is significantly faster than switching between full processes because the memory address space (page tables) does not need to be updated.

2. Process States & The PCB

• Five classic states:

1. New — process being created.
2. Ready — loaded in memory, waiting for the CPU.
3. Running — instructions being executed on the CPU.
4. Waiting/Blocked — waiting for some event (I/O, a lock).
5. Terminated — finished; resources reclaimed.

• Transitions to remember: Ready → Running (scheduler dispatch), Running → Ready (preempted/time-slice), Running → Waiting (I/O request), Waiting → Ready (I/O completes).

• PCB (Process Control Block): the OS’s per-process data structure — process ID, state, program counter, registers, scheduling info, memory-management info, open-file list, I/O status. The PCB is the object a context switch saves and restores.

• Zombie vs. Orphan:

• Zombie: a child that has finished but whose parent hasn’t called wait(), so its PCB lingers. Harmless (few KB) but shouldn’t accumulate.

• Orphan: a child whose parent died first; it’s re-parented to init/PID 1, which reaps it. No exit code is lost.

3. User-Level vs. Kernel-Level Threads

This is a favorite for interviewers testing your knowledge of thread implementation.

Feature	User-Level Threads	Kernel-Level Threads
Management	Managed by User Libraries (e.g., POSIX Threads).	Managed by the OS Kernel directly.
Visibility	Kernel is unaware of these threads.	Kernel is aware of and schedules each thread.
Blocking	If one thread makes a blocking system call, the entire process blocks.	If one thread blocks, the kernel can schedule another thread in the same process.
Performance	Faster context switching (no mode switch).	Slower (requires mode switch to Kernel).

• Multithreading models: Many-to-One (all user threads → one kernel thread; cheap but one block stops all), One-to-One (each user thread → own kernel thread; true parallelism, costly), Many-to-Many (multiplex many user threads onto several kernel threads; best of both, complex).

4. Types of Operating Systems

• Batch OS: jobs grouped and run with no user interaction; maximize throughput. Poor response time.
• Time-Sharing (Multitasking): CPU time-sliced among interactive users; each gets a fast response.
• Real-Time OS (RTOS): guarantees a response within a deadline.
• Hard RT: a missed deadline is a total failure (airbag, pacemaker).
• Soft RT: deadlines matter but a rare miss is tolerable (video streaming, gaming).
• Distributed OS: multiple machines appear as one system; shares resources over a network.
• Embedded/Mobile: resource-constrained, often RTOS-based.

Multiprogramming vs. Multitasking vs. Multiprocessing:

• Multiprogramming: many jobs loaded; CPU switches when one waits on I/O (keeps CPU busy). One CPU.
• Multitasking: multiprogramming extended to user interaction — rapid time-slicing so users feel simultaneous execution. One CPU.
• Multiprocessing: multiple physical CPUs/cores executing truly in parallel. Many CPUs.

5. Dual Mode, System Calls & Privileged Instructions

• Dual-mode: the CPU has two privilege levels. Kernel mode (mode bit 0) can execute any instruction; user mode (mode bit 1) cannot. This isolates user programs from the hardware and each other.
• Privileged instructions (kernel-only): setting the timer, I/O device access, changing the mode bit, interrupt/exception handling, memory-management operations (loading page-table base register), halt. A user program attempting these causes a trap.
• System call flow:

1. User program calls a library wrapper (e.g., printf → write).
2. The wrapper executes a trap instruction, switching to kernel mode.
3. The kernel dispatches to the right handler via the system-call number.
4. It executes the privileged work, returns a result, and switches back to user mode.

• fork() vs exec(): fork() clones the current process into a new child (returns 0 to child, PID to parent); exec() replaces the current process image with a new program. Together they run a new program: fork, then exec in the child.

6. The Boot Process

1. BIOS/UEFI runs from firmware, does a Power-On Self-Test (POST), and locates the boot device.
2. It loads the bootloader (GRUB) from the disk’s boot sector.
3. The bootloader loads the kernel into memory.
4. The kernel initializes hardware, mounts the root file system, and starts the first process (init/systemd, PID 1), which spawns the rest of the system.

• One-liner: firmware → bootloader → kernel → init.

7. Logical vs. Physical Address (Memory Binding)

The CPU never sees a physical RAM address; it only deals with Logical Addresses.

• The Translation Mechanism:
• CPU: Generates a logical address.
• MMU (Memory Management Unit): The hardware component that maps the logical address to a physical RAM address using a Page Table.
• Dynamic Loading/Linking: Modern systems use dynamic linking (shared libraries), where code is not loaded into memory until it is actually called, saving significant memory.

8. Fragmentation: The Memory Waster

When the OS manages memory, it often ends up with unusable “gaps.”

• Internal Fragmentation: Occurs when the OS allocates a fixed-size block (e.g., 4KB page) to a process, but the process only needs 3KB. That 1KB is wasted inside the allocated space.
• External Fragmentation: Occurs over time as processes are loaded and removed. You may have 50MB of free RAM total, but it is broken into 5MB chunks scattered everywhere. A process requiring a single 10MB block cannot be loaded, even though there is 50MB available.
• The Solution: Paging solves external fragmentation because it allows a process to be stored in non-contiguous physical memory frames.

9. Paging vs. Segmentation (Deep Dive)

These are the two main strategies for managing non-contiguous memory.

• Paging (Hardware-driven):

• Divides logical memory into fixed-size blocks called Pages.

• Divides physical memory into fixed-size blocks called Frames.

• Pros: No external fragmentation; easy to swap pages to disk.

• Cons: Internal fragmentation (the last page is rarely full).

• Segmentation (User-view driven):

• Divides memory into logical units: Code, Data, Stack, Main, Function, Library.

• Segments are of variable length.

• Pros: Fits the way programmers view code; allows sharing of specific segments (e.g., sharing a single library between multiple processes).

• Cons: External fragmentation (the OS must use algorithms like First-Fit or Best-Fit to find space).