Skip to content

CS 631-02 Systems Foundations — Meeting Summary

  • Date: May 05, 2026
  • Time: 02:47 PM Pacific Time (US and Canada)
  • Meeting ID: 882 2309 0019

Note: The transcript used multiple names for the kernel/codebase (e.g., Octox/Octo/Octoks and OkDux/Oktox). For clarity, this summary standardizes on Octox (kernel) and OkDux (codebase).

Quick Recap

  • Greg led a technical session on virtual memory and system calls in the Octox kernel.
  • He guided students through setting up Python virtual environments and configuring the run_octox.py script for Project 5’s autograder (requires the PExpect library).
  • Topics included:
  • Virtual memory, page tables, and address translation
  • User-to-kernel transitions via system calls (e.g., getPID)
  • Trampoline code enabling safe transitions between user and kernel space
  • Memory mapping between virtual and physical addresses and the role of the TLB/translation cache
  • He emphasized strategies for understanding large codebases, previewed process scheduling, and introduced upcoming kernel modifications for the final project.

Next Steps

  • Greg

  • Release the next project (kernel modifications) by the end of the week.

  • Collaboration

  • All students: Create a Python virtual environment (VENV) and install the PExpect library to run run_octox.py for the Project 5 autograder.
  • All students: Resolve issues running run_octox.py; seek help from Greg/Shreyas as needed.
  • All students: Use cloud.md for Project 5 setup and troubleshooting.
  • All students: Attend Thursday’s session for deeper coverage of process scheduling and virtual memory.

Detailed Summary

Python Virtual Environment Setup

  • The class reviewed how to:
  • Create and activate a Python virtual environment (VENV).
  • Install non-standard dependencies (PExpect) inside the VENV.
  • Use VS Code (with Cloud Code extension) to work on the kernel.
  • The plan includes upcoming coverage of virtual memory and kernel tracing.

Python VENV Management and Build Notes

  • Demonstration of VENV creation and management using Homebrew and pip.
  • Showed activation, library installation, and running Python apps within a VENV.
  • Addressed a build issue in Octox LS that was resolved with cargo clean.
  • The discussion briefly touched on Zsh before moving on.

Python Environment Practices

  • Recommended approach:
  • Use system package managers for system-level Python.
  • Use user-level virtual environments for project-specific dependencies.
  • Investigated a VS Code syntax highlighting issue, likely due to missing OS/kernel configuration.
  • Noted improvements in Claude’s code handling compared to a previous model.

VS Code JSON Configuration

  • Demonstrated editing JSON-based settings in VS Code.
  • Highlighted that JSON does not allow comments.
  • Mentioned installing a VS Code extension and logging in with a Pro account; unclear if it reuses an existing Cloud Code installation.
  • Reiterated the complexity of kernel and Rust code, and noted Octox as a useful environment for learning Rust.

OkDux Codebase and Process Management

  • OkDux is self-contained (akin to bare-metal), with core components implemented in-source.
  • Emphasized learning to navigate large, complex codebases.
  • Covered key OS concepts:
  • Process control blocks (PCBs)
  • Concurrency in multi-core environments
  • Kernel synchronization mechanisms (to be detailed in upcoming sessions)
  • Previewed upcoming projects involving kernel changes.

Evolution of Concurrency in Operating Systems

  • Historical context:
  • Single-core systems relied on interrupts (e.g., timer interrupts) for limited concurrency.
  • Early multi-processor Linux used a “big kernel lock” (sledgehammer lock) to serialize kernel execution for simplicity and debuggability.
  • Modern approach:
  • True concurrent kernel execution with fine-grained synchronization (e.g., mutexes) to maintain data structure consistency under contention.

Process States and Structure

  • Common process states: sleeping, waiting, running, zombie.
  • Lifecycle: allocated → running/blocked → completed → unallocated.
  • Process data structures include:
  • Kernel stack
  • UVM (user virtual memory page table)
  • File descriptor table
  • Additional attributes (e.g., scheduling metadata)
  • Virtual memory was queued as the next topic.

Octox Memory Layout

  • On RISC-V:
  • Virtual memory is split into kernel and user virtual address spaces.
  • Kernel virtual address space:
    • Maps all RAM
    • Uses a kernel page table
    • Is shared across processes
  • User virtual address space:
    • Private to each process
    • Uses a per-process page table mapping

Virtual Memory Translation in Octox

  • Page tables map user virtual addresses to physical addresses.
  • The processor uses a translation cache (e.g., TLB) to accelerate lookups.
  • Stack and heap considerations:
  • User stack is limited to 4 KiB in Octox; large arrays cannot be stack-allocated.
  • Heap allocations span multiple pages and are mapped via the page table, enabling larger data structures.

Virtual Memory and System Calls

  • Virtual memory is an OS abstraction that maps virtual to physical addresses via kernel-managed page tables.
  • Accessing unmapped memory triggers faults (e.g., segmentation faults).
  • Security note:
  • Buffer overflows in C can enable code injection; a historical example was discussed from early Netscape browsers.
  • System calls (e.g., getPID) in Octox:
  • An ecall transfers control from user to kernel mode.
  • The kernel saves register state in a trap frame.
  • A syscall dispatcher routes requests via a syscall table.
  • Trampoline code mediates safe transitions between user and kernel spaces.