https://ansangah.github.io/en/tags/systemprogramming/SystemProgrammingHugo Blox Builder (https://hugoblox.com)enWed, 30 Apr 2025 00:00:00 +0000https://ansangah.github.io/media/sharing.pnghttps://ansangah.github.io/en/tags/systemprogramming/https://ansangah.github.io/en/blog/subjects/os/Wed, 30 Apr 2025 00:00:00 +0000https://ansangah.github.io/en/blog/subjects/os/<h2 id="1-history-and-concepts">1. History and Concepts</h2> <h3 id="11-batch-processing">1.1 Batch Processing</h3> <ul> <li>Early OSes executed a single job at a time with no user intervention.</li> <li>Operators manually queued jobs; the next job started only after the previous finished.</li> <li>Idle CPU time abounded while waiting for I/O, making computation inefficient.</li> </ul> <h3 id="12-limitations-of-batch">1.2 Limitations of Batch</h3> <ol> <li><strong>CPU idle time:</strong> Fast CPUs waited for slow I/O devices.</li> <li><strong>Slow job switching:</strong> Manual intervention delayed the transition between jobs.</li> </ol> <h3 id="13-spooling-fixes-issue-1">1.3 Spooling (Fixes Issue 1)</h3> <ul> <li>Buffers I/O so computation and device work overlap.</li> <li>Example: printer spooling—documents are queued on disk; printers fetch at their own pace while the CPU continues other work.</li> <li>Benefit: CPU need not stall for I/O completion.</li> <li>Caveat: If the program depends immediately on I/O results (e.g., <code>read()</code>), spooling alone cannot help.</li> </ul> <h3 id="14-automatic-job-sequencing-fixes-issue-2">1.4 Automatic Job Sequencing (Fixes Issue 2)</h3> <ul> <li>Scheduling software automatically loads the next job as soon as the previous one finishes.</li> <li>Improves throughput compared with manual batching.</li> <li>Requires <strong>multiprogramming</strong> to keep multiple jobs resident in memory.</li> </ul> <h3 id="15-multiprogramming--time-sharing">1.5 Multiprogramming &amp; Time Sharing</h3> <ul> <li>Multiple jobs reside in memory; CPU switches to another while the current one waits for I/O.</li> <li>FCFS plus priority-based policies balance fairness.</li> <li><strong>Time sharing:</strong> CPU time is sliced so each job sees frequent progress. Heavy context switching gives the illusion of concurrency but adds overhead.</li> </ul> <hr> <h2 id="2-os-and-computer-system-structure">2. OS and Computer-System Structure</h2> <h3 id="21-four-components">2.1 Four Components</h3> <ol> <li><strong>Hardware:</strong> CPU, memory, I/O devices provide raw resources.</li> <li><strong>Operating System:</strong> Arbitrates resource access among programs.</li> <li><strong>Application Programs:</strong> Decide how resources are used to satisfy user tasks.</li> <li><strong>Users:</strong> People or other systems interacting with the computer.</li> </ol> <h3 id="22-bus-architecture">2.2 Bus Architecture</h3> <ul> <li>Early machines used a single bus—CPU, memory, I/O shared one channel—causing bottlenecks.</li> <li><strong>Hierarchical dual-bus</strong> design emerged: <ul> <li><strong>System bus:</strong> connects fast CPU/memory.</li> <li><strong>I/O bus:</strong> connects slower peripherals.</li> <li><strong>Northbridge:</strong> controller for high-speed devices.</li> <li><strong>Southbridge:</strong> handles slower devices and legacy ports.</li> </ul> </li> </ul> <hr> <h2 id="3-execution-modes-user-vs-kernel">3. Execution Modes: User vs. Kernel</h2> <ul> <li>CPUs provide at least two privilege levels for system protection.</li> <li>Each mode controls which instructions and memory regions are accessible.</li> </ul> <h3 id="31-kernel-mode">3.1 Kernel Mode</h3> <ul> <li>Privileged; OS services, drivers, and resource managers run here with full hardware access.</li> </ul> <h3 id="32-user-mode">3.2 User Mode</h3> <ul> <li>Restricted; applications cannot execute privileged instructions and must request services via the OS.</li> </ul> <h3 id="33-mode-switching">3.3 Mode Switching</h3> <ul> <li>System calls, interrupts, and traps flip the mode bit and jump into kernel handlers.</li> <li>After handling, control returns to user mode at the interrupted point.</li> </ul> <hr> <h2 id="4-cpu-event-handling">4. CPU Event Handling</h2> <h3 id="41-hardware-interrupts">4.1 Hardware Interrupts</h3> <ul> <li>Asynchronous events from devices.</li> <li>Sequence: save context → jump to ISR → perform service → restore context → resume execution.</li> <li>Priorities decide which interrupts pre-empt others; keep ISRs short.</li> </ul> <h3 id="42-traps-software-interrupts">4.2 Traps (Software Interrupts)</h3> <ul> <li>Synchronous events within a program: e.g., divide-by-zero, system calls.</li> <li>Trigger a switch to kernel mode but may reuse existing context without full saving.</li> </ul> <h3 id="43-io-device-components">4.3 I/O Device Components</h3> <ul> <li><strong>Bus:</strong> data, address, and control lines.</li> <li><strong>Device registers:</strong> control, status, input, output; mapped to memory for CPU access.</li> <li><strong>Controller:</strong> intermediates between devices and buses, arbitrating use.</li> </ul> <hr> <h2 id="5-device-access-methods">5. Device Access Methods</h2> <h3 id="51-io-instructions">5.1 I/O Instructions</h3> <ul> <li>CPU-specific instructions communicate directly with devices.</li> <li>Non-portable because instruction sets differ.</li> </ul> <h3 id="52-memory-mapped-io">5.2 Memory-Mapped I/O</h3> <ul> <li>Maps device registers into the main address space so ordinary loads/stores access hardware.</li> <li>Improves portability and programming simplicity.</li> </ul> <hr> <h2 id="6-io-completion-techniques">6. I/O Completion Techniques</h2> <h3 id="61-polling">6.1 Polling</h3> <ul> <li>CPU repeatedly checks device status.</li> <li>Fast response for quick devices but wastes CPU cycles when waiting.</li> </ul> <h3 id="62-interrupt-driven-io">6.2 Interrupt-Driven I/O</h3> <ul> <li>CPU continues other tasks until a device interrupts to signal completion.</li> <li>Saves busy-wait time but incurs context-switch overhead and may delay detection of very fast events.</li> </ul> <blockquote class="border-l-4 border-neutral-300 dark:border-neutral-600 pl-4 italic text-neutral-600 dark:text-neutral-400 my-6"> <p><strong>Rule of thumb:</strong> Fast devices favour polling; slower ones benefit from interrupts.</p> </blockquote> <hr> <h2 id="7-data-transfer-methods">7. Data Transfer Methods</h2> <h3 id="71-programmed-io">7.1 Programmed I/O</h3> <ul> <li>CPU performs all data movement; expensive for large transfers.</li> </ul> <h3 id="72-direct-memory-access-dma">7.2 Direct Memory Access (DMA)</h3> <ul> <li>A DMA controller transfers data between memory and devices on behalf of the CPU.</li> <li>Process: CPU issues command → DMA moves data → completion interrupt notifies CPU.</li> <li>Pros: frees CPU cycles; excels for high-volume transfers.</li> <li>Cons: additional hardware cost and possible bus contention.</li> </ul> <hr> <h2 id="8-os-design-considerations">8. OS Design Considerations</h2> <h3 id="81-general-vs-special-purpose">8.1 General vs. Special Purpose</h3> <ul> <li>General-purpose OSes serve diverse workloads; special-purpose OSes target embedded, real-time, or appliance scenarios.</li> <li>Balancing performance, fairness, and reliability requires deliberate trade-offs.</li> </ul> <h3 id="82-layering-vs-modularity">8.2 Layering vs. Modularity</h3> <ul> <li><strong>Layering:</strong> strict top-down structure; upper layers use lower-layer services only.</li> <li><strong>Modularity:</strong> independent components communicate through explicit interfaces; freer ordering but demands dependency management.</li> <li>Modern OSes blend both: layered architecture populated with modular subsystems for stability and extensibility.</li> </ul> <hr> <h2 id="9-kernel-structures-and-system-calls">9. Kernel Structures and System Calls</h2> <h3 id="91-system-calls--mode-switch">9.1 System Calls &amp; Mode Switch</h3> <ul> <li>User code invokes an API → generates a trap → CPU enters kernel mode → trap handler executes → returns to user mode.</li> </ul> <h3 id="92-parameter-passing">9.2 Parameter Passing</h3> <ol> <li><strong>Registers:</strong> fastest but few parameters fit.</li> <li><strong>Memory blocks:</strong> store arguments in memory and pass the address.</li> <li><strong>Stack:</strong> push arguments in user mode; kernel pops them.</li> </ol> <h3 id="93-monolithic-kernel">9.3 Monolithic Kernel</h3> <ul> <li>All kernel services share one address space.</li> <li>Pros: minimal overhead for cross-service calls.</li> <li>Cons: tightly coupled; a faulty module can crash the entire kernel.</li> </ul> <h3 id="94-address-spaces">9.4 Address Spaces</h3> <ul> <li>Define accessible address ranges. Sharing the same space allows direct referencing; separate spaces reinforce protection boundaries.</li> </ul> <h3 id="95-microkernel">9.5 Microkernel</h3> <ul> <li>Decomposes services into user-space servers communicating via IPC.</li> <li>Pros: low coupling, easy maintenance, unload unused services.</li> <li>Cons: frequent address-space switches and IPC overhead can hurt performance.</li> </ul> <h3 id="96-hybrid-kernel">9.6 Hybrid Kernel</h3> <ul> <li>Real-world kernels typically combine monolithic cores with loadable modules or user-space servers, balancing performance and flexibility.</li> </ul>