UNIT 4: OPERATING SYSTEMS - COMPREHENSIVE NOTES

Based strictly on the provided blueprint and analysis of past RGPV examination papers (Jun 2025, Jun 2024, Jun 2023, Nov 2023, Dec 2024, Nov 2022, Jun 2022).

I. OPERATING SYSTEM OVERVIEW & FUNDAMENTALS

Evolution of Operating Systems [FREQUENT]

A chronological progression driven by hardware and user needs:

1. Batch Systems: Jobs grouped by similar requirements; no user interaction. Goal: Maximize CPU utilization.

2. Multiprogrammed Systems: Multiple jobs in memory; CPU switches to another when one waits (I/O). Goal: Increase CPU utilization.

3. Time-Shared (Multitasking) Systems: CPU switches rapidly among multiple interactive users. Goal: Response time, convenience.

4. Network Operating Systems: Provides file/print sharing across a LAN. Key: Resource sharing over a network.

5. Distributed Operating Systems: Appears as a single system; resources distributed across independent machines. Key: Transparency, scalability.

6. Real-Time Operating Systems (RTOS): Must meet strict timing constraints. Types: Hard (guaranteed deadline), Soft (occasional miss acceptable).

Major Functions & Services of an OS [FREQUENT]

Operating System Structure [FREQUENT]

• Monolithic: All OS components in a single kernel (large, fast, but hard to maintain). Example: Traditional UNIX.

• Layered: OS divided into layers (0: hardware, N: user interface). Each layer uses only lower layers. Advantage: Easier to construct/debug.

• Microkernel: Minimal kernel (memory management, process scheduling, IPC). Other services (drivers, file system) run in user space as servers. Advantage: Extensibility, reliability, portability. Example: Mach.

• Modular: Loadable kernel modules (e.g., device drivers) added dynamically.

[!TIP] UNIX System Structure (Layered Model) [FREQUENT]

1. Hardware

2. Kernel: Process management, memory management, I/O, file system.

3. System Calls Interface

4. Shell & Utilities (User Programs)

System Programs & Utility Programs [FREQUENT]

• System Programs: Provide a convenient environment for program development/execution.

  • Command Interpreters (Shells): sh, bash, csh.

  • System Utilities: File management (cp, mv), status info (ps, top), language support (compilers, interpreters).

• Utility Programs: Perform specific maintenance tasks (backup, antivirus, disk defragmentation).

Operating System Types [FREQUENT]

II. PROCESS MANAGEMENT

Process Concept

• Process vs. Program: A program is passive code; a process is an active execution instance (program counter, registers, memory, resources). One program can create many processes.

• Process States & State Diagram [FREQUENT]

  
  graph LR
  
  New --> Ready;
  
  Ready --> Running;
  
  Running --> Waiting;
  
  Running --> Terminated;
  
  Waiting --> Ready;
  
  

  • New: Being created.

  • Ready: Waiting for CPU.

  • Running: Instructions being executed.

  • Waiting/Blocked: Waiting for an event (I/O, signal).

  • Terminated: Execution finished.

• Process Control Block (PCB) [FREQUENT]

  The kernel's data structure for process management. Contains:

  • Process State

  • Process ID (PID)

  • CPU Registers (saved during context switch)

  • CPU Scheduling Info (priority, scheduling queue pointers)

  • Memory Management Info (page tables, base/limit)

  • Accounting Info (CPU time used, limits)

  • I/O Status Info (open files, allocated I/O devices)

Process Scheduling

• Scheduling Queues:

  • Job Queue: All processes in system.

  • Ready Queue: Processes in main memory, ready to run.

  • Device Queues: Processes waiting for a specific I/O device.

• Schedulers:

  • Long-term (Job Scheduler): Admits processes from job pool to main memory (controls degree of multiprogramming).

  • Short-term (CPU Scheduler): Selects ready process for CPU execution (fast, runs frequently).

  • Medium-term (Swapper): Removes/returns processes to/from memory to control multiprogramming level.

CPU Scheduling Algorithms [FREQUENT - HIGH PRIORITY]

Key Metrics:

• Turnaround Time = Completion Time - Arrival Time

• Waiting Time = Turnaround Time - Burst Time

• Response Time = First CPU allocation - Arrival Time (for time-sharing)

[!TIP] Common Pitfall: For RR, if q > Burst Time, process finishes in its turn. Last process in a cycle may have shorter burst than q.

Threads & Concurrency

• Thread vs. Process:

  | | Process | Thread | | :--- | :--- | :--- | | Resource | Own address space, resources. | Shares process resources (memory, files). | | Overhead | High (create, switch, destroy). | Low (create, switch, destroy). | | Communication | IPC (slow). | Direct (read/write shared memory - fast). | | Isolation | High (one crash doesn't affect others). | Low (erroneous thread can corrupt process). |

• User-Level vs. Kernel-Level Threads [FREQUENT - VERY HIGH]

  | | User-Level Threads | Kernel-Level Threads | | :--- | :--- | :--- | | Management | By user-space thread library. | By OS kernel. | | Scheduling | Kernel unaware; 1-to-1 with process. | Kernel schedules each thread. | | Blocking | Entire process blocks if one thread blocks (system call). | Only blocking thread blocks. | | Context Switch | Fast (no mode switch). | Slower (kernel mode switch). | | Portability | High (library not OS-dependent). | Low (OS-dependent). | | Example | POSIX Pthreads (user), Java threads (user). | Windows NT/2000/XP threads, Linux clone(). |

• Virtual Concurrency vs. Real Concurrency [FREQUENT]

  • Virtual Concurrency: Single CPU; OS switches between threads/processes rapidly, appearing simultaneous.

  • Real Concurrency: Multiple CPUs/Cores; true simultaneous execution of threads/processes.

Interprocess Communication (IPC)

• Shared Memory: Processes share a region of memory. Fastest IPC. Requires synchronization (semaphores).

• Message Passing: Processes exchange messages via kernel-provided primitives (send, receive). Slower, but easier for distributed systems.

• Pipes: Unidirectional byte stream connection between related processes (parent-child). Implemented via kernel buffer.

• Named Pipes (FIFOs): Like pipes but have a name in the file system; allow unrelated processes to communicate.

Synchronization

• Critical Section Problem: Code segment accessing shared resource. Requirements: Mutual Exclusion, Progress, Bounded Wait.

• Peterson's Solution [FREQUENT]

  For two processes Pi and Pj. Uses two shared arrays: flag[2] (interest) and turn.

  
  // Entry Section
  
  flag[i] = true;
  
  turn = j;
  
  while (flag[j] && turn == j) ; // busy wait
  
  // Critical Section
  
  // Exit Section
  
  flag[i] = false;
  
  

• Semaphores [FREQUENT]

  Integer variable S with two atomic operations:

  • wait(S) / P(S): while (S <= 0) ; S--;

  • signal(S) / V(S): S++;

  • Binary Semaphore (Mutex): S = 0 or 1. Used for mutual exclusion.

  • Counting Semaphore: S >= 0. Used for resource counting.

  Usage for Critical Section:

  semaphore mutex = 1;

  wait(mutex);

  // Critical Section

  signal(mutex);

• Monitors [FREQUENT]

  High-level synchronization construct. A monitor is a module with:

  1. Shared variables (private to monitor).

  2. Procedures/functions (only one active at a time).

  3. Condition variables (wait, signal) for blocking/waking.

  Dining Philosophers Solution (Monitor):

  monitor DiningPhilosophers {

  enum { THINKING, HUNGRY, EATING } state[5];

  condition self[5];

  void pickup(int i) {

  state[i] = HUNGRY;
  

  test(i);
  

  if (state[i] != EATING) self[i].wait();
  

  }

  void putdown(int i) {

  state[i] = THINKING;
  

  test((i+4)%5); test((i+1)%5);
  

  }

  void test(int i) {

  if (state[i]==HUNGRY && state[(i+4)%5]!=EATING && state[(i+1)%5]!=EATING) {
  

    state[i] = EATING;
  

    self[i].signal();
  

  }
  

  }

  initialization() { for i=0 to 4 state[i]=THINKING; }

  }

III. DEADLOCKS

Deadlock Definition & Necessary Conditions [FREQUENT]

A set of processes is in deadlock if each process waits for an event that can only be caused by another process in the set. Four necessary conditions (must hold simultaneously):

1. Mutual Exclusion: At least one resource must be held in non-sharable mode.

2. Hold and Wait: Process holding at least one resource is waiting for additional resources held by others.

3. No Preemption: Resources cannot be forcibly taken away.

4. Circular Wait: A circular chain of processes exists, where each waits for a resource held by the next.

Deadlock Handling Methods

1. Deadlock Prevention: Ensure at least one necessary condition never holds.

   • Break Mutual Exclusion: Only for sharable resources (e.g., read-only files).

   • Break Hold and Wait: Require processes to request all resources at once (low utilization, starvation possible).

   • Break No Preemption: Preempt resources if needed (complex, may cause work loss).

   • Break Circular Wait: Impose a total ordering on resource types; request in increasing order.

2. Deadlock Avoidance: Dynamically check if granting a request leads to an unsafe state. Requires knowing max future needs.

   • Banker's Algorithm [FREQUENT - VERY HIGH]

     • Data Structures:

       • Available[1..m]: Available instances of each resource type.

       • Max[n][m]: Maximum demand of each process.

       • Allocation[n][m]: Currently allocated resources.

       • Need[n][m] = Max - Allocation.

     • Safety Algorithm (Check if state is safe):

       1. Work = Available, Finish[i] = false for all i.

       2. Find i such that Finish[i]==false and Need[i] <= Work. If none, go to 4.

       3. Work = Work + Allocation[i], Finish[i] = true. Go to 2.

       4. If Finish[i]==true for all i, state is SAFE.

     • Resource-Request Algorithm:

       1. If Request[i] > Need[i], error (exceeded max claim).

       2. If Request[i] <= Available, allocate. Else, process waits.

       3. Check if new state is safe. If yes, allocate; if no, process waits.

3. Deadlock Detection & Recovery:

   • Detection: Use Resource Allocation Graph (RAG) for single instance resources. For multiple instances, use Wait-For Graph (WFG) (nodes=processes, edge Pi->Pj if Pj holds resource Pi wants). Periodically run cycle detection.

   • Recovery:

     • Process Termination: Terminate all deadlocked processes (brute force) or one by one (minimize cost).

     • Resource Preemption: Select victim process, rollback to safe state (checkpointing), possibly cause starvation.

4. Deadlock Ignorance (Ostrich Algorithm): Assume deadlocks never occur (used in many general-purpose OS like Windows, Linux). Restart if occurs.

IV. MEMORY MANAGEMENT

Basic Concepts

• Physical vs. Logical Address Space: Logical (virtual) address generated by CPU; Physical address seen by memory unit.

• Contiguous vs. Non-Contiguous Allocation:

  • Contiguous: Process occupies a single contiguous block of memory. Leads to External Fragmentation (holes between allocated blocks).

  • Non-Contiguous: Process split into blocks/pages/segments placed anywhere. No external fragmentation (but may have internal).

• Internal vs. External Fragmentation [FREQUENT]

  • Internal Fragmentation: Allocated memory > requested memory (wasted within allocated block). Caused by fixed-size allocation units (pages, fixed partitions).

  • External Fragmentation: Total memory space enough for a request, but not in a single contiguous block. Caused by variable-size allocation (dynamic partitions).

Contiguous Allocation

• Fixed Partitioning: Memory divided into fixed-sized partitions. Internal fragmentation (if process < partition).

• Variable Partitioning (Dynamic): Partition size = process size. External fragmentation.

• Placement Algorithms [FREQUENT]:

  | | First-Fit | Best-Fit | Worst-Fit | | :--- | :--- | :--- | :--- | | Strategy | Allocate first hole big enough. | Allocate smallest hole big enough. | Allocate largest hole. | | Speed | Fastest (search from start/marker). | Slowest (search entire list). | Slow (search entire list). | | Fragmentation | Tends to leave small holes at start. | Tends to leave many small holes. | Tends to leave many medium holes. |

Paging

• Concept: Divide physical memory into fixed-size frames (e.g., 4KB). Divide logical memory into same-size pages. Page table maps page number -> frame number. Logical address = [Page #][Offset].

• Protection using Paging [FREQUENT]: Valid-Invalid bit in page table entry. 1 = valid (page in process's address space), 0 = invalid (page not present or access violation) → trap to OS.

• Page Table Structure:

  • Hierarchical (Multi-level): Page table too big? Page the page table. Example: Two-level (IA-32).

  • Hashed: For large address spaces (SPARC, x86-64). Hash page # to PTEs.

  • Inverted: One entry per physical frame, contains <virtual page, process> pairs. Shared pages have multiple entries.

• Demand Paging [FREQUENT]

  • Concept: Bring page into memory only when needed (on page fault). Valid-Invalid bit = 0 initially.

  • Page Fault: Trap to OS when accessing invalid page. OS:

    1. Finds free frame (if none, uses page replacement).

    2. Schedules I/O to read page from disk (swap space/file).

    3. Updates page table, sets Valid bit.

    4. Restarts instruction.

  • Working Set Model: Set of pages a process has used recently. If working set in memory → low page fault rate. If not → thrashing.

• Page Replacement Algorithms [FREQUENT - VERY HIGH]

  Goal: Minimize page fault rate. Need to know reference string.

  | Algorithm | Idea | Belady's Anomaly? | | :--- | :--- | :--- | | FIFO | Replace page that has been in memory longest. | YES (more frames → more faults). | | Optimal (OPT) | Replace page that will not be used for longest time in future. | NO (theoretical minimum). | | LRU | Replace page that has not been used for longest time in past. | NO (approximates OPT). | | Second-Chance | FIFO with reference bit check. If R=1, set R=0, move to end. | Usually no. |

  [!TIP] Page Fault Calculation Steps:

  1. Initialize empty frames.

  2. For each reference in string:

  *   If page in frame → **Hit** (no fault).
  

  *   If page not in frame & free frame available → **Fault**, load page.
  

  *   If page not in frame & no free frame → **Fault**, use replacement algo to choose victim, load page.
  

  3. Count total faults.

Segmentation

• Concept: User's view of memory. Divide program into logical segments (code, data, stack, heap). Each segment has a number and offset. Logical address = <Segment #, Offset>.

• Segment Table: Maps segment # to base physical address and limit (segment length). Check 0 <= offset < limit.

• Segmentation with Paging (Paged Segmentation) [FREQUENT]

  • Each segment is paged. Segment table points to page tables for each segment.

  • Advantages: Combines user's logical view (segments) with efficient physical memory use (paging). No external fragmentation (paging), but internal fragmentation (pages). Protection/sharing at segment level.

• Advantages of Segmentation over Paging [FREQUENT]

  • User/Coder Friendly: Reflects program's logical structure.

  • Easier Sharing & Protection: Share entire segment (e.g., procedure) with appropriate protection bits per segment.

  • No Internal Fragmentation: Segment size = exact program need (but may have external fragmentation).

Virtual Memory [FREQUENT]

• Definition: Technique that allows execution of processes that may not be completely in memory. Key Idea: Only parts of a process needed for execution reside in memory.

• Benefits:

  • Larger Logical Address Space than physical memory.

  • Memory Protection: Each process has its own address space.

  • Efficient Memory Use: Only active pages/segments in memory.

  • Simplifies Programming & Loading: Programmer need not worry about physical memory limits; OS handles loading.

Overlay [FREQUENT]

• Concept: Manual method to run large programs on small memory. Programmer divides program into self-contained modules (overlays). Only needed overlay loaded into memory at a time. Overlays loaded/unloaded by explicit code.

• Usefulness: Useful for embedded systems or very old systems without virtual memory. Drawback: Complex for programmer; OS not involved.

Memory Management in Specific OS [FREQUENT]

• UNIX (e.g., BSD):

  • Uses paging with demand paging.

  • Swap Space: Disk area for swapped-out pages (separate partition or file).

  • Page Replacement: Modified Second-Chance algorithm.

  • Page Table: Per-process, with page table entry (PTE) containing frame #, valid bit, dirty bit, reference bit, protection bits.

  • Working Set: Maintained via page fault frequency.

• Windows (e.g., Windows XP/10):

  • Uses demand paging with working set per process.

  • Virtual Address Space: 2GB user, 2GB kernel (32-bit); 128TB user, 128TB kernel (64-bit).

  • Page File: pagefile.sys on system drive (configurable size).

  • Page Replacement: Modified Clock algorithm (similar to Second-Chance, uses dirty bit).

  • Page Table: Per-process, hierarchical (PML4, PDP, PD, PT on x64).

V. STORAGE MANAGEMENT: FILE SYSTEMS

File System Structure & Modules [FREQUENT]

Layered organization:

1. I/O Control: Device drivers, interrupt handlers. Reads/writes disk sectors.

2. Basic File System: Issues read/write requests to I/O control. Manages buffers/caches.

3. File Organization Module: Knows files & their logical blocks. Maps logical block # to physical block (contiguous, linked, indexed).

4. Logical File System: Manages metadata (directory structure, file control blocks - FCBs/Inodes). Provides API (open, read).

5. Virtual File System (VFS) [FREQUENT]: Provides common interface to multiple file system types (ext4, NTFS, NFS). Defines vnode (virtual inode) and file operations (vop_read, vop_write). Allows transparent access to local/remote files.

Directory Structure

File System Implementation

Disk Space Allocation Methods [FREQUENT - VERY HIGH]

Free-Space Management

• Bit Vector (Bitmap): 1 bit per block. 0=free, 1=allocated. Simple, fast with bit manipulation.

• Linked List: Free blocks linked together. Each free block contains list of other free blocks.

• Grouping: First free block contains addresses of n free blocks. Last block points to next group.

• Counting: Keep list of (address, count) for contiguous free blocks (like variable partitions).

File System in Specific OS [FREQUENT]

• UNIX (e.g., ext4):

  • Inode (Index Node): Fixed-size metadata structure per file. Contains: mode (type, permissions), link count, owner, size, timestamps, block pointers (12 direct, 1 indirect, 1 double, 1 triple).

  • Directory: Special file containing <inode #, filename> pairs.

  • Performance: Fast for small/medium files (direct pointers). Large files use multi-level indirection. Journaling (ext3/4) for consistency.

• Windows (NTFS - New Technology File System):

  • Master File Table (MFT): Central database. Each file is a record in MFT (like inode).

  • Attributes: $$\displaystyle STANDARD_INFORMATION` (timestamps, permissions), ` $$FILE_NAME, $DATA (file content), etc.

  • Extents: Uses (starting cluster, length) pairs for data runs (contiguous clusters) instead of block pointers. Efficient for large files.

  • Features: Journaling, security descriptors (ACLs), hard/soft links, compression, encryption.

• Comparison: UNIX vs. Windows File Systems [FREQUENT]

  | Feature | UNIX (ext4) | Windows (NTFS) | | :--- | :--- | :--- | | Metadata Structure | Inode (fixed size, separate from directory). | MFT record (variable size, part of MFT). | | Data Pointers | Direct, indirect, double, triple pointers. | Extents (run-list: start cluster, length). | | Journaling | Yes (ext3/4). | Yes (NTFS log). | | Security | Traditional UNIX permissions (UID/GID, rwx). | ACLs (more granular). | | Max File Size | 16TB (4KB block, 48-bit pointers). | 16EB (theoretical). | | Performance | Good for small files; multi-level indirection for large. | Better for large, sequential files (extents). |

File Protection & Security [FREQUENT]

• Access Types: Read (r), Write (w), Execute (x), Append (a), Delete (d).

• File Protection Methods:

  • Access Control Lists (ACLs): Per-file list of <user/group, permissions>. Used in NTFS, modern UNIX (NFSv4 ACLs).

  • Capabilities: Tokens (capabilities) held by processes, granting specific access rights. Less common in desktop OS.

  • Passwords: File-level passwords (rare, insecure).

• System Security & Protection Mechanisms:

  • Authentication: Verify identity (passwords, biometrics, tokens).

  • Authorization: Determine allowed operations (ACLs, groups).

  • Encryption: Protect data at rest (file system encryption - e.g., BitLocker, FileVault) or in transit (TLS/SSL).

  • Audit Trails: Log security-relevant events (login attempts, file access).

VI. STORAGE MANAGEMENT: DISK & I/O SYSTEMS

Disk Structure & Performance

• Disk Geometry: Platters → Tracks (concentric circles) → Sectors (fixed-size blocks, e.g., 512B/4KB) → Cylinder (same track # across platters).

• Disk Performance Parameters [FREQUENT]

  • Seek Time (T_s): Time to move head to target track. Dominant component.

  • Rotational Latency (T_r): Time for sector to rotate under head. Average = 1/2 * rotation time.

  • Transfer Time (T_t): Time to read/write sector once under head. T_t = (sector size) / (transfer rate).

  • Access Time (T_a) = T_s + T_r + T_t.

  • Bandwidth: Total data transferred per unit time.

Disk Scheduling Algorithms [FREQUENT - VERY HIGH]

Goal: Minimize total seek time (dominant). Assume head starts at 143, previous at 125, requests: 86, 147, 91, 177, 94, 150, 102, 175, 130. Tracks 0-199.

Disk Management

• Disk Formatting:

  • Physical Formatting (Low-level): Divide disk into sectors (done by manufacturer).

  • Logical Formatting (High-level): Create file system structures (boot block, superblock, inodes, data blocks). Example: mkfs.

• Disk Mounting [FREQUENT]

  • Mount Point: An existing directory (e.g., /mnt/usb) where the root of a file system is attached.

  • Process: OS reads superblock of device, verifies file system, integrates its directory tree into the global VFS tree at the mount point. Subsequent accesses to mount point path go to that device.

• Bad Block Management: Mark bad sectors during formatting (low-level) or during operation (logical bad block forwarding). Use spare sectors.

I/O SYSTEMS

• I/O Hardware: I/O bus connects CPU/memory to controllers (disk controller, USB controller). Controllers manage devices via registers (data, control, status).

• Application I/O Interface:

  • Block Devices: Access in fixed-size blocks (disks). Seek, read block, write block.

  • Character Devices: Access as stream of bytes (terminals, printers). No seeking.

• Kernel I/O Subsystem [FREQUENT]

  • Functions:

    1. Scheduling: Queue I/O requests (e.g., elevator algorithm).

    2. Buffering: Store data temporarily (in main memory) to cope with device-CPU speed mismatch or different data unit sizes.

    3. Caching: Keep copies of data in faster memory (e.g., disk cache in RAM).

    4. Spooling: Hold output for a device that cannot accept interleaved data (e.g., printer spooler).

    5. Device Reservation: Provide exclusive access (e.g., flock).

    6. Error Handling: Detect and correct I/O errors (bad sectors, timeouts).

• Logical Structure of I/O Function [FREQUENT]

  
  User Process
  
      |
  
  (System Call Interface: open, read, write)
  
      |
  
  I/O System (Kernel)
  
      |--> I/O Scheduler (queues, elevator)
  
      |--> Buffer/Cache Management
  
      |--> Device Driver Interface
  
      |
  
  Device Driver (specific to controller)
  
      |
  
  Hardware (Controller, Device)
  
  

I/O Operations

• Synchronous vs. Asynchronous I/O [FREQUENT - VERY HIGH]

  | | Synchronous (Blocking) | Asynchronous (Non-Blocking) | | :--- | :--- | :--- | | Process | Waits (blocked) until I/O completes. | Continues execution; I/O happens in background. | | System Call | Returns only after data copied to user buffer. | Returns immediately (may return partial data or error). | | Notification | Implicit (wake-up on completion). | Explicit (signal, callback, polling). | | Complexity | Simpler programming model. | More complex, but better for I/O-intensive or GUI apps. | | Example | read(fd, buf, n) blocks until n bytes read. | aio_read() returns immediately; completion via signal. |

• Interrupt-Driven I/O [FREQUENT]

  1. Process issues I/O syscall → driver starts device → process blocks.

  2. Device controller performs I/O independently.

  3. On completion, controller interrupts CPU.

  4. CPU saves context, jumps to Interrupt Service Routine (ISR) in driver.

  5. ISR reads status, signals waiting process, returns from interrupt.

  6. Scheduler may reschedule another process.

• I/O Buffering [FREQUENT]

  • Purpose: Match speed mismatch, block size differences, support semantics (e.g., read after write must return old data).

  • Single Buffer: OS allocates one buffer in kernel space. User process waits for buffer fill (blocking) or gets partial data (non-blocking). Problem: Context switch per block.

  • Double Buffer: Two buffers. While process consumes one, OS fills other. Reduces wait, but context switch still needed.

  • Circular Buffer: Multiple buffers in a ring. Producer (I/O) fills next buffer, consumer (process) empties previous. Efficient for streams (audio, video).

I/O Management in Specific OS [FREQUENT]

• UNIX:

  • Device Files: All I/O devices appear as special files in /dev (e.g., /dev/sda, /dev/tty). Use same open/read/write syscalls.

  • Kernel Structure: Device drivers register with VFS. Character devices use cdev structure, block devices use gendisk + request_queue. Streams subsystem for STREAMS I/O (e.g., networking).

• Windows:

  • I/O Manager: Central kernel component. Provides NtReadFile, NtWriteFile syscalls.

  • Device Drivers: WDM (Windows Driver Model) / KMDF (Kernel-Mode Driver Framework). Plug-and-Play, power management.

  • Asynchronous I/O: Native support via I/O Completion Ports (IOCP) for high-performance servers. ReadFileEx with completion routine or IOCP.

VII. SYSTEM CALLS & PROTECTION

System Call Concept

The programmed interface between user-space applications and the OS kernel. Provides controlled access to protected kernel resources. Invoked via software interrupt (int 0x80 on x86) or special instructions (syscall).

Types of System Calls [FREQUENT]

1. Process Control: fork, exec, exit, wait, getpid, kill.

2. File Management: open, close, read, write, lseek, mkdir, rmdir, link, unlink.

3. Device Management: ioctl, read, write (on device files).

4. Information Maintenance: gettimeofday, stat, fstat.

5. Communication: pipe, shmget, msgsnd, socket.

System Call Examples [FREQUENT]

• Process Management:

  • fork(): Creates child process (copy of parent). Returns 0 to child, child's PID to parent.

  • exec() family (execl, execv): Replaces current process image with new program.

  • wait()/waitpid(): Parent waits for child termination.

  • exit(status): Terminates calling process.

  • getpid(): Returns calling process's PID.

• File Management:

  • open(path, flags, mode): Opens file, returns file descriptor (FD).

  • close(fd): Closes file.

  • read(fd, buf, count): Reads count bytes into buf from FD.

  • write(fd, buf, count): Writes count bytes from buf to FD.

  • lseek(fd, offset, whence): Moves file offset (seek).

  • stat(path, buf): Gets file status (size, timestamps, permissions) into buf.

  • ioctl(fd, request, argp): Device-specific control operations (e.g., set terminal mode).

Dynamic Linking & Loading [FREQUENT]

• Concept: Linking of library code (e.g., libc.so) at load time or runtime, not at compile time (static linking).

• Advantages:

  1. Memory Saving: Single copy of shared library (e.g., libc) in memory, used by all processes.

  2. Easier Updates: Update library file once; all programs using it get new version automatically (no recompilation).

  3. Reduced Executable Size: Executable doesn't contain library code.

• Mechanism: Stub in executable points to library. On first call (or load), dynamic linker (ld.so) loads library into memory, resolves symbols, patches stub.

VIII. ADVANCED & SPECIAL TOPICS

Tape Organization [FREQUENT]

• Tape Drives: Sequential access storage. No random access. Read/write in blocks.

• Access Methods:

  • Forward Space Records (FSR): Skip n records forward.

  • Backward Space Records (BSR): Skip n records backward.

  • Rewind: Move to beginning.

  • Retension: Tighten tape (for old tapes).

• Use Cases: Archival backup, large-scale data transfer (physical shipment). Disadvantage: Slow random access.

Real-Time Operating Systems (RTOS) [FREQUENT]

• Characteristics:

  • Deterministic: Response time predictable, bounded.

  • High Reliability: Fault-tolerant.

  • Priority-Based Preemptive Scheduling: Highest priority ready task always runs.

  • Minimal Latency: Interrupt handling, context switch times in microseconds.

  • Special Features: Watchdog timers, memory locking (no paging), priority inheritance (to prevent priority inversion).

• Scheduling: Often Rate-Monotonic (RM) for periodic tasks (shorter period → higher priority) or Earliest Deadline First (EDF) (dynamic priority based on deadline).

Multiprocessor & Distributed OS Differences [FREQUENT]

Network Operating Systems [FREQUENT]

• Characteristics:

  • Network Awareness: Built-in protocols (TCP/IP, SMB/CIFS, NFS).

  • Remote Resource Access: Transparent file/print sharing.

  • User/Group Management: Centralized (domain controller) or distributed.

  • Security: Authentication across network (Kerberos), firewalls.

  • Scalability: Support many clients/servers.

• Differences from Traditional OS:

  • Primary Focus: Network communication and resource sharing vs. local resource management.

  • Services: File/print services, directory services, authentication services are core.

  • Kernel: Often includes network stack, file system clients (NFS, SMB).

  • Example: Windows Server, Linux with Samba/NFS.

END OF UNIT 4 NOTES