Skip to content

CS 631-01 Systems Foundations — Meeting Summary

  • Date: Apr 28, 2026
  • Time: 08:14 AM Pacific Time (US and Canada)
  • Meeting ID: 870 0988 0761

Quick Recap

The session covered processes and process management in Unix-like operating systems (using OctoX as the course system). Greg explained the relationship between kernel code and user applications, including: - Address spaces and process control blocks (PCBs) - Kernel scheduling and multiplexing across multiple cores - System calls with a focus on fork and exec - File descriptor management and redirection

Live code demonstrations showed how new processes are created, how programs can be replaced within a running process, and how to redirect output by manipulating file descriptors. The next meeting will continue with pipes and additional process management topics.

Next Steps

  • Greg:
  • Update the GitHub repository with fixes to example programs, especially those related to fork, exec, and redirection.
  • Apply any additional updates identified during the session.
  • Continue the discussion and demonstration of pipes and file descriptor manipulation in the next meeting (Thursday).

Collaboration

  • All participants:
  • Pull the latest updates from the GitHub repository to obtain the corrected example code.

Detailed Summary

Operating System Process Model

  • The discussion focused on how the kernel and user applications interact, distinguishing user space and kernel space.
  • The kernel manages processes using data structures like the process control block (PCB).
  • Scheduling enables multiple processes to share limited CPU cores through multiprogramming/multitasking.

Process Memory and System Calls

  • Processes cannot access memory outside their allocated address space.
  • To access kernel services (e.g., file I/O, terminal output), processes invoke system calls.
  • A system call switches the CPU from user mode to kernel mode (via the eCall instruction), switching from the user stack to the kernel stack.
  • Each process has both a user stack and a kernel stack (tracked in its PCB), enabling safe context switches.

Kernel Blocking and System Calls

  • Using read as an example, the session explained how the kernel can block a process and track its state via the stack.
  • Covered process-related system calls to be used or discussed: fork, exec, wait, and redirection basics.
  • Reviewed default file descriptors: stdin (0), stdout (1), stderr (2), and Unix file creation/open modes.

Command-Line Arguments and File Access

  • The kernel populates a new process’s argument list on the user stack so the program can access argv/argc (or language-specific equivalents).
  • Discussed Rust idioms: iterators and expect for error handling.
  • Explained common file access patterns: open → read/write → close, and the concept of memory-mapped files.
  • Noted that Unix determines end-of-file by byte count rather than a special EOF character.

Reliability and Isolation

  • Emphasized the role of processes and isolated address spaces in OS reliability.
  • Early smartphones lacked robust multi-programming and isolation, causing instability.
  • Modern systems (e.g., iOS based on Unix) improved reliability through strong isolation and process models.

fork System Call Overview

  • fork creates a new process that is initially an exact copy of the parent’s code, data, and stack.
  • Parent and child are distinguished by return values:
  • Child: typically sees a return value of 0.
  • Parent: sees the child’s PID as the return value.
  • fork can fail due to out-of-memory conditions or exhaustion of process table entries.
  • Code examples demonstrated PID assignment and parent/child distinction.

Process Management System Calls: Demo Highlights

  • fork creates a new execution stream in a separate address space.
  • exec replaces the current process image with a new program.
  • Modifying a variable in the child does not affect the parent, demonstrating separate address spaces.
  • exit terminates a process properly.
  • wait allows a parent to wait for child completion.

Process IDs and fork Behavior

  • Parent and child receive different PIDs.
  • On real Unix systems, PIDs can wrap upon reaching a maximum value (this behavior may differ in OctoX).
  • Execution order between parent and child after fork is non-deterministic.
  • Upcoming topics: exec with redirection and how shells implement redirection between files and commands.

Fork Implementation Details and Concurrency

  • Demonstrations showed interleaved output from parent and child running on different cores.
  • Explained copy-on-write (COW): pages are shared as read-only and only copied on modification.
  • Linux and macOS typically use COW.
  • OctoX, for teaching clarity, may perform a full copy.
  • fork is commonly followed by exec to run new programs (e.g., in multi-core servers).

Process Creation and Redirection

  • Demonstrated using fork + exec to start new programs.
  • Showed output redirection by manipulating file descriptors:
  • Closing and reopening specific descriptor slots (e.g., replacing stdout with a file) redirects output.
  • Unix’s separation of fork and exec enables setup steps like redirection and pipe creation before executing the new program.
  • Pipes and more advanced redirection techniques will be covered in the next session (Thursday).

For questions or to propose additional examples, participants should coordinate via the course repository and discussion channels.