Operating System Structures &
Processes — Structured Study Notes
1) Executive Summary
An operating system (OS) is the software layer that sits between
users/applications and hardware, acting as both a resource allocator and a
control program. It provides essential services such as program execution, I/O,
file management, communication, protection, and error handling while keeping the
system efficient and fair. In practice, modern OSs are built using different
structures—simple, layered, microkernel, modular, and hybrid—and they
manage work through processes, states, scheduling, PCB, and context
switching.
2) Core OS Idea
What an OS does
● Acts as an intermediary/interface between the user and hardware.
● Helps users run programs easily and efficiently.
● Allocates CPU, memory, files, and devices fairly among competing tasks.
● Prevents errors and improper use through controlled access.
Major OS services
● User interface: CLI, GUI, or batch style interaction.
● Program execution: load, run, and terminate programs.
● I/O operations: handle files and devices.
● File-system manipulation: create, delete, read, write, and protect
files/directories.
● Communication: shared memory or message passing.
● Error detection: monitor hardware and software failures.
● Resource allocation, accounting, protection, security.
3) OS Architecture and Structure
A. Simple structure
● Minimal separation between parts.
● Example: MS-DOS.
● Fast and small, but weak modular separation.
B. Layered approach
● OS is divided into layers.
● Each layer uses services only from lower layers.
● Layer 0 = hardware; top = user interface.
C. Microkernel structure
● Moves as much as possible out of kernel space into user space.
● Components communicate via message passing.
● Advantages: easier to extend, port, and secure.
● Tradeoff: communication overhead.
D. Modules
● Modern OSs often use loadable kernel modules.
● Each component is separate but connected through known interfaces.
● More flexible than strict layers.
E. Hybrid systems
● Most real OSs combine approaches.
● Example ideas from the slides:
○ Linux/Solaris: monolithic core + modular loading
○ Windows: mostly monolithic with subsystem personalities
○ macOS: hybrid of Mach + BSD + I/O kit + modules
4) System Calls, Kernel Mode, and User Mode
Why system calls exist
User programs should not directly access privileged hardware operations. When a
program needs services like file access, memory growth, process creation, or I/O,
it requests the kernel through a system call. The OS uses a system-call interface
and a table of call numbers to dispatch the correct kernel routine.
Step-by-step mechanism
1. A user program invokes an API function or direct system call.
2. The system-call interface looks up the call number in its table.
3. Control transfers to the kernel.
4. The kernel executes the requested service.
5. Status and return values go back to the program.
User mode vs kernel mode
● User mode: normal application execution.
● Kernel mode: privileged OS execution.
● A mode bit helps hardware distinguish the two.
● System calls switch from user mode to kernel mode and back again.
5) Booting and OS Startup
Basic boot sequence
1. Power on.
2. BIOS/firmware runs POST.
3. Firmware looks for the boot loader in the MBR/boot sector.
4. Boot loader loads the kernel.
5. Kernel initializes core services and device drivers.
6. OS becomes ready for users.
6) Process Concept
A process is a program in execution. A program on disk is passive; once loaded
into memory and started, it becomes active as a process. One program can create
multiple processes, especially when multiple users run it at the same time.
Process memory layout
● Text section: program code
● Data section: global variables
● Heap: dynamic memory during runtime
● Stack: function parameters, local variables, return addresses
● Current activity: program counter and CPU registers
7) Process States
A process moves through five major states:
● New: being created
● Ready: waiting for CPU
● Running: executing instructions
● Waiting: blocked for I/O or an event
● Terminated: finished execution
State transition logic
● New → Ready: admitted
● Ready → Running: scheduler dispatch
● Running → Ready: interrupt/time slice expires
● Running → Waiting: requests I/O/event
● Waiting → Ready: I/O/event completes
● Running → Terminated: exit
8) Process Control Block (PCB)
The PCB stores everything the OS needs to pause and later resume a process. It
includes:
● process state
● program counter
● CPU registers
● CPU scheduling information
● memory-management information
● accounting information
● I/O status information
Why PCB matters
When the CPU switches from one process to another, the OS saves the old
process state and restores the new one from PCB. That switching work is context
switch overhead.
9) Process Scheduling
The scheduler’s job is to maximize CPU use and keep the system responsive. The
OS maintains several queues:
● Job queue: all processes in the system
● Ready queue: processes in memory ready for CPU
● Device queues: processes waiting for an I/O device
Types of schedulers
● Long-term scheduler: decides which jobs enter the ready queue; controls
degree of multiprogramming.
● Short-term scheduler: chooses the next ready process for CPU; runs very
frequently.
● Medium-term scheduler: swaps processes out and back in to control
memory pressure.
Key idea
● CPU-bound processes need long CPU bursts.
● I/O-bound processes spend more time waiting for devices.
● Good scheduling tries to balance both for stable performance.
10) Structural Diagram
11) Process State Diagram
12) Step-by-Step Mechanisms
A. How a system call works
1. Application requests a service.
2. API / call interface receives the request.
3. OS switches to kernel mode.
4. Kernel performs the operation.
5. Control returns to the application with result or error code.
B. How a context switch works
1. Running process is interrupted or yields CPU.
2. OS saves CPU state into its PCB.
3. Scheduler selects another ready process.
4. OS restores that process’s PCB state.
5. CPU continues with the new process.
C. How scheduling works
1. Processes enter the job queue.
2. Ready processes wait in memory.
3. CPU scheduler picks one.
4. Process runs until it blocks, exits, or is interrupted.
5. It moves among ready, waiting, and terminated states as events occur.
13) 3 Real-World Engineering Examples
1. Printing in an office network
A document is sent to the printer, but the printer is slower than the computer. The
OS uses spooling to place print jobs in a buffer so the CPU can continue working
while the printer processes jobs one by one.
2. Running a desktop app on Linux or FreeBSD
When a user launches an editor or browser, the shell creates a process using calls
such as fork() and exec(). The process then moves through ready/running/waiting
states depending on CPU time and I/O requests.
3. Mobile multitasking on Android
Android supports foreground and background work through its Linux-based stack,
process management, and services. Background services can keep running even
when the app is not visible, which is a real example of OS-level process and
resource management.
14) Quick Revision Points
● OS = interface + resource manager + control program.
● System calls are the gateway to kernel services.
● Processes have states, memory layout, PCB, and context-switch behavior.
● Scheduling uses queues and different schedulers to balance performance
and fairness.
● Real OSs are usually hybrid, not pure monolithic or pure microkernel.