Operating System Concepts - Chapter 2: Services and System Calls (VOCAB)

2.1 Introduction

• An operating system (OS) provides the environment in which programs are executed.
• OS designs vary greatly due to different goals and architectures; goals must be well defined before design begins to guide algorithm and strategy choices.
• Perspectives on an OS:
  • Services provided by the OS.
  • Interface exposed to users and programmers.
  • Components and their interconnections.
• Chapter focus: three viewpoints (users, programmers, OS designers) and topics:
  • What services OS provides and how they are provided and debugged.
  • Design methodologies for OS construction.
  • How an OS is created and how a computer starts its OS (boot process).
• Chapter objectives:
  • Identify services provided by an OS.
  • Illustrate how system calls provide OS services.
  • Compare monolithic, layered, microkernel, modular, and hybrid OS designs.
  • Illustrate the booting process of an OS.
  • Apply tools for monitoring OS performance.
  • Design and implement kernel modules for interacting with a Linux kernel.

2.2 Operating-system services

• OS provides an execution environment and makes services available to programs and users.

• Common classes of OS services (Figure 2.2.1 shows their interrelations):

  • GUI, user interfaces, and command line interfaces for interaction with the system.
  • Program execution: loading a program into memory, running it, and handling normal or abnormal termination.
  • I/O operations: OS provides a controlled I/O mechanism; direct device access by users is generally restricted for efficiency and protection.
  • File-system manipulation: read/write files and directories, create/delete, search, list information, and, in some systems, access control (permissions) for files/directories.
  • Communications: inter-process communication (IPC) either via shared memory or message passing.
  • Error detection and handling: detect and correct errors from CPU/memory, I/O devices, and user programs; may halt the system or terminate offending processes.
  • Resource allocation: manage CPU time, memory, file storage, and other resources; includes CPU scheduling and device allocation.
  • Logging: track resource usage for accounting and statistics, aiding system reconfiguration and administration.
  • Protection and security: protect resources from interference, authenticate users, defend against external threats, and monitor for break-ins; a chain is only as strong as its weakest link.

• A second set of OS functions focuses on the OS itself for efficiency in a multi-process environment (resource sharing).

• 2.2.1 Section review questions

  • Q: Which OS service is related to ensuring efficient operation of the system and is unrelated to providing services to user programs?
  • Answer: Resource allocation

• Glossary highlights (selected definitions):

  • user interface (UI): a method by which a user interacts with a computer.
  • graphical user interface (GUI): window system with pointing device and keyboard input.
  • touch-screen interface: interaction by touching the screen.
  • command-line interface (CLI): text-based commands entered via keyboard.
  • shared memory: IPC where a memory region is shared by multiple processes.
  • message passing: IPC via sending/receiving messages between processes or computers.

2.3 User and operating-system interface

• Three fundamental approaches for user interaction with the OS:

  • Command-line interface (CLI) / command interpreter (shells in systems with multiple interpreters).
  • Graphical user interface (GUI).
  • Touch-screen interface (mobile devices).

• Command interpreters (shells):

  • OSes (Linux, UNIX, Windows) treat the command interpreter as a separate program that runs when a user logs in or a process starts interactive mode.
  • Multiple shells may exist (e.g., C shell, Bourne-Again shell, Korn shell).
  • Two general command execution models:
  • Interpreter contains code to execute the commands directly.
  • Most commands are implemented as separate programs; the interpreter identifies the command and loads the corresponding program for execution.
  • Benefit of the second model: easy addition of new commands by simply adding new programs; the interpreter need not be modified.

• Graphical user interface (GUI):

  • Uses a windowing system with a desktop metaphor; icons, folders, menus, and windows accessed with a mouse and keyboard.
  • GUIs originated in part from Xerox PARC (the Xerox Alto, 1973) and popularized by Apple Macintosh in the 1980s.
  • UNIX tradition favored CLI; open-source GUI projects include KDE and GNOME on Linux/UNIX.
  • Touch-screen interfaces adapted for mobile devices (iOS, Android) with gestures and on-screen keyboards.

• Choice of interface: largely a matter of preference and task suitability.

  • System administrators and power users often prefer CLI for efficiency and scripting capabilities.
  • GUI is common for general users; some tasks may be limited to GUI in certain systems.
  • Some systems provide both GUI and CLI; macOS provides Aqua GUI and a UNIX-based CLI.

• Notable examples and notes:

  • Shell scripting enables recording a sequence of commands and executing them as a program (interpreted by the shell).
  • iOS and Android devices emphasize touch interfaces; desktop OSes emphasize GUI and CLI balance.

• 2.3.1 Section review questions

  • Q: A ___ is another term for a command interpreter.
  • Answer: shell

• Glossary highlights (selected terms):

  • command interpreter: OS component that interprets user commands and triggers actions.
  • shell: one of several command interpreters on a system with multiple interpreters.
  • desktop: GUI workspace on screen where tasks are executed.
  • icons/folders: GUI concepts for objects and grouping of files.
  • gestures: touch-based actions (e.g., pinching, swiping).
  • springboard: iOS touch-screen interface.
  • system administrators / power users: users with advanced system knowledge.
  • shell script: a file containing a set of commands for the shell.

2.4 System calls

• System calls provide an interface to the OS services; typically exposed as C/C++ functions and may be written in assembly for low-level tasks.

• Example: a simple program to read data from one file and copy to another, illustrating the use of system calls and the potential APIs involved.

  • Ways to specify file names: through command-line arguments (e.g., UNIX cp in.txt out.txt) or via interactive prompts and GUI menus.
  • Key operations in the copy sequence:
  • Obtain two file names (input and output) via prompts or command-line arguments.
  • Open input file and create/open output file; handle errors (file not found, permissions, existing destination file).
  • Copy data in a loop: read from input file, write to output file; handle read/write errors (end-of-file, parity errors, disk space issues).
  • Close files, report completion, and terminate normally.

• API, system calls, and RTE (runtime environment):

  • API (Application Programming Interface): set of functions available to an application programmer; examples include Windows API, POSIX API, Java API.
  • RTE (run-time environment): software needed to execute applications in a given language, including compilers/interpreters, libraries, loaders, etc.
  • The API invokes underlying system calls; the system-call interface is a table of numbers mapping to kernel services.
  • The caller generally does not know how a system call is implemented; the API abstracts the complexity.
  • Example: read() in UNIX/Linux:
  • 
    ssizet read(int fd, void *buf, sizet count);
    
  • Parameters:
  • fd: file descriptor to read from.
  • buf: destination buffer.
  • count: maximum number of bytes to read.
  • Return value: number of bytes read; 0 indicates end-of-file; -1 indicates error.

• Why use an API instead of direct system calls?

  • Portability: program compiled against an API can run on any system supporting the same API.
  • API abstracts complexities of direct system calls; the API and the underlying system calls are often similar across POSIX/Windows.
  • The RTE mediates API calls to system calls; it uses a system-call interface table to dispatch calls.

• Types of system calls (rough categories):

  • Process control: create/terminate processes, load/execute, get/set process attributes, wait/signal events, allocate/free memory.
  • File management: create/delete files, open/close, read/write/reposition, get/set file attributes.
  • Device management: request/release device, read/write/reposition, get/set device attributes, attach/detach devices.
  • Information maintenance: get/set time/date, get system data, get/set attributes of processes/files/devices.
  • Communications: create/delete communication connections, send/receive messages, transfer status information, attach/detach remote devices.
  • Protection: get/set file permissions, etc.

• Figure 2.4.4 (types of system calls) and related descriptions summarize these categories.

• 2.4.1 Mid-section review question

  • Q: An interface to the services made available by an operating system is called an ___.
  • Answer: Application Programming Interface (API)

• The handling of a user application invoking a system call (example flow for open()):

  • The user application makes a call to open().
  • The system call interface transfers control from user mode to kernel mode.
  • The kernel uses the system-call table to locate the implementation of open().
  • The system call is executed by the kernel and a return value is produced to user mode.
  • The system-call implementation may perform parameter validation and perform the requested operation (e.g., open a file).
  • The open() result may be a file descriptor or an error code returned to the user application.
  • This flow can be depicted as: user application -> system-call interface -> kernel implementation(open) -> return to user application.

• Parameter passing to system calls:

  • Three general methods exist:
  • In registers (fast, limited by number of registers).
  • A table or block in memory whose address is passed (used when more than a few parameters are required).
  • Pushed onto a stack (for flexible, possibly many parameters).
  • Linux often uses a mix: registers for up to five parameters; more than five may use a memory block/table approach.
  • Figure 2.4.3 illustrates passing parameters via a table.

• 2.4.2 The Handling of a User Application Invoking the open() System Call (flow diagram):

  • User mode -> system call table lookup -> system call implementation -> return to user mode.
  • The system call interface intercepts the call and transfers control to the kernel, then returns control to user space.

• 2.4.3 Section review questions

  • Q1: Which of the following is not a major category of system calls? (Process control / Communications / Security / Cache memory)
  • Q2: Which technique is not a method for passing parameters to a system call? (Registers / Cache memory / Stack)

• Selected glossary terms related to system calls:

  • system call: Software-triggered interrupt allowing a process to request a kernel service.
  • API: A set of commands/functions/tools used by programmers.
  • libc: The standard C library on UNIX/Linux that provides APIs and wraps system calls.
  • run-time environment (RTE): Software needed to execute applications in a language (compiler/interpreters, libraries, loaders).
  • system-call interface: The mechanism that links user programs/API calls to kernel system calls.
  • push / stack: Data structures used to pass parameters; stacks use LIFO ordering.

• Figure 2.4.2: The relationship between API, the system-call interface, and the OS (illustrative model of invoking open()).

2.5 System services

• System services or system utilities extend the kernel with convenient tools to support development and execution of programs.

• Categories of system services:

  • File management: create/delete/rename/copy/list files and directories; manipulate files and directories; map files to storage.
  • Status information: access system status such as time, memory, disk space, number of users; format/output data for display (terminal/window).
  • File modification: text editors and tools to search/transform contents.
  • Programming-language support: compilers, assemblers, debuggers, interpreters.
  • Program loading and execution: loaders (absolute/relocatable), linkers, overlay loaders; debugging tools for languages.
  • Communications: mechanisms for inter-user or inter-process communication; e.g., messaging, couriers across networks.
  • Background services: daemons and system processes started at boot time; some run long-term, others terminate after tasks complete.

• Daemons and background services

  • Daemons: system programs that run in the background to provide services (e.g., network daemon).
  • Services/subsystems/daemons help run tasks continuously or at scheduled times.
  • Some services run in user context (not necessarily in kernel context).

• 2.5.1 Section review questions

  • Q1: Which option is not considered a form of a system utility? (Application programs / Programming language support / Background services)

• Other notes:

  • The user view of the OS is influenced by the applications and system programs, not only the raw system calls.
  • The same OS can present different views through different interfaces (CLI vs GUI) yet use the same underlying system calls.

2.6 Resource management

• The OS acts as a resource manager for CPU, memory, storage, and I/O devices.

• Core areas of resource management:

  • Process management:
  • A process is an active execution of a program; a program by itself is passive (a file on disk).
  • A single-threaded process has one program counter; multithreaded processes have multiple counters.
  • A system may create subprocesses; processes may execute concurrently, either via multiplexing on a single CPU core or in parallel on multiple cores.
  • OS responsibilities include:
    • Creating/deleting user and system processes.
    • Scheduling processes and threads on CPUs.
    • Suspending and resuming processes.
    • Providing mechanisms for process synchronization and communication.
  • Memory management:
  • Main memory is a large array of bytes addressed by the CPU for instruction fetch and data operations.
  • Programs must be loaded into memory with absolute addresses; memory is reclaimed when processes terminate.
  • Memory-management schemes balance CPU utilization and system responsiveness; hardware characteristics influence algorithm choice.
  • File-system management:
  • Abstraction of storage as a logical file; mapping logical files to physical mass storage; directories organize files; access control may apply (permissions).
  • Mass-storage management (secondary storage):
  • Provides persistent storage using HDDs, SSDs, etc.; secondary storage is used to back up main memory and host programs/data until loaded.
  • OS responsibilities: mounting/unmounting, free-space management, storage allocation, disk scheduling, partitioning, protection.
  • Tertiary storage (e.g., magnetic tape, optical media) used for backups and archival storage; management may be partial or handled by applications.
  • Cache management and hierarchy:
  • Caching speeds up computation by storing frequently accessed data in faster storage (registers, L1/L2 caches, etc.).
  • Cache levels (illustrative example):
    • Level 1: registers, typical size < 1 KB; access time ~ 0.25-0.5 ext{ ns}; located in processor registers.
    • Level 2: cache, size < 16 MB; access time ~ 0.5-25 ext{ ns}; hardware cache.
    • Level 3: main memory, size < 64 GB; access time ~ 80-250 ext{ ns}; memory hierarchy continues to SSD/Disk.
    • Level 4: solid-state disk (SSD) < 1 TB; access time and bandwidth vary; fast storage tier.
    • Level 5: magnetic disk < 10 TB; larger, slower storage.
  • Replacement policies and cache coherence are important in multi-core and multi-processor systems.
  • Cache coherency ensures updates in one cache are reflected in all caches; hardware often handles coherency below the OS level.
  • In distributed environments, replicas across machines require synchronization to maintain consistency.
  • I/O subsystem and device management:
  • I/O hides device heterogeneity from applications using: buffering, caching, spooling, and a device-driver interface.
  • Device drivers implement device-specific details; interrupt handlers coordinate I/O completion.
  • The I/O subsystem connects to the rest of the OS components and manages data transfers.

• 2.6.1 Section review questions

  • Q1: Two important design issues for cache memory are and .
  • Answer: speed and replacement policy (as inferred from context; size and volatility can appear in other questions, but the emphasized design issues here are speed and replacement policy).
  • Q2: An instance of a program in execution is called a ___.
  • Answer: process

• Additional key terms from 2.6:

  • resource manager: the OS role in managing computer resources.
  • program counter: a CPU register indicating the address of the next instruction to load and execute.
  • I/O subsystem: the I/O devices and the kernel portion that manages I/O.
  • daemon: a background service that runs without direct user interaction.

• Connections to broader topics and real-world relevance:

  • OS services map to APIs used by applications; most developers work at the API level, not at raw system calls.
  • The RTE + API + system call interface form the chain from application code to kernel execution; the API hides implementation details and enables portability.
  • Efficient I/O, memory management, and storage hierarchy are critical for performance, especially in multi-user and multi-process environments.
  • Security and protection are foundational to modern networked systems; protection mechanisms prevent unauthorized access and ensure data integrity across processes.

• Practical implications and examples:

  • A shell-based workflow enables rapid task automation and scripting, saving time for repetitive tasks.
  • GUI vs CLI trade-offs affect system administration, human-computer interaction, and task automation approaches.
  • Understanding system calls and APIs helps in debugging, performance tuning, and cross-platform development.
  • Multi-process and multi-threaded execution require careful memory and synchronization management to avoid race conditions and ensure data integrity.

• Connections to real-world systems:

  • Windows, POSIX, and Java APIs illustrate how language- and platform-specific APIs provide access to underlying OS services.
  • The Arduino example shows single-tasking versus multitasking behavior, boot loaders, and event-driven sketches in embedded systems.
  • FreeBSD example demonstrates forking and exec() for process creation in a multitasking OS, including background execution and shell control.

• Quick recap of terminology (select glossary items used in this chapter):

  • system call, API, libc, RTE, system-call interface, push/stack, process, thread, cache coherency, I/O subsystem, daemon, client/server, shared memory, message passing, registry, service, subsystem, application program.

• Notable figures and concepts to remember for exams:

  • The three OS viewpoints: services, interface, and components.
  • The six major types of system calls and their sub-areas.
  • The role of the RTE and the mapping from API calls to system calls.
  • The storage hierarchy and the concept of cache coherency across multiple processors.
  • The I/O subsystem design and the separation of drivers from device-specific details.

• End of notes for Chapter 2 (Operating System Concepts):

  • Review questions correspond to each section, reinforcing understanding of the material.