Meeting Summary: CS 631-02 Systems Foundations¶

Date: May 14, 2026
Time: 02:56 PM Pacific Time (US and Canada)
Meeting ID: 882 2309 0019

Quick Recap¶

The lecture reviewed kernel-level implementations of core system calls—fork, exec, and wait—relevant to Project 6. Greg walked through:

How new processes are created (memory management, page tables, context switching).
How fork clones a process (page tables and file descriptors).
How exec replaces a process image (loading code pages and reconstructing the stack).
A new process-tracking feature requiring additions to the proc struct and two system calls (sys_track_self and sys_track_wait) to gather syscall and memory metrics.

Implement sys_track_self to set the track Boolean in the current process’s proc struct.
Implement sys_track_wait to:
Wait for a tracked child to complete.
Populate and copy out a track metrics struct to user space.
Extend the proc struct with dynamic tracking metrics (e.g., per-syscall counters).
Instrument:
The syscall entry path to increment counters for tracked processes.
The read and write system calls to track bytes read/written.
On tracked process exit, collect and store:
PID, name, exit code.
Syscall counts.
Memory layout (text, stack, heap).
Page table/page counts.
Implement user-level support in the track program to:
Allocate a track metrics struct.
Call sys_track_wait.
Print formatted metrics.
Notify Greg and Trace on Campus Wire about the autograder/repo issue (grid reverting to 0 after repo recreation).

Emphasized fork’s role in Project 6 and the flow from user mode to kernel mode.
Noted that a CPU core runs in either user or kernel context at any moment—key to understanding the track program’s behavior.

Covered the trampoline page and trap frame and how they manage control transfer and address translation.
Reviewed the user virtual address space: code, static data, stack, possible heap.
Explained how virtual-to-physical mappings are handled via page tables and how free memory is managed.

Described building a new user page table and copying parent data to the child.
Discussed using fixed-size proc structs and separating synchronized vs. unsynchronized fields for performance.
Highlighted working patterns for Rust’s borrow checker and synchronization in kernel code.

During fork:
Allocate and map kernel pages for the trampoline and trap frame.
Prepare the kernel context so the child returns at the fork return point, then transitions to user space.
Noted that certain initialization (e.g., file system) must happen in the context of a process (handled by the event process).
Next step is copying page tables from parent to child.

Algorithm overview:
For each mapped VA in the parent: locate the PTE, obtain the PA, allocate a new page, copy contents, and map into the child with identical permissions.
Update the child’s size, copy parent registers into the child trap frame, set the child’s return value to 0, and mark the child runnable.

Kernel work involves low-level CPU state handling and multicore synchronization but need not be slow.
Potential plan to rebuild OpTex using simpler Rust constructs for educational clarity.
Time complexity considerations: OpTex targets efficient process isolation and memory multiplexing with minimal bookkeeping.

fork:
Clones parent memory, page tables, and file descriptors.
exec:
Replaces the process image by parsing an ELF binary, allocating a new page table, loading segments, and building a new stack.
Explained ELF format basics and kernel parsing/loading steps.

Steps:
Allocate pages for code and data; load program segments.
Construct the stack in C ABI layout (arguments, and optionally environment variables).
Free old page table mappings after the new image is prepared.
After a short break, the lecture moved to the wait implementation and a guide narrating kernel operations from user calls to system behavior.

Discussed using QEMU to emulate a VGA device for pixel updates.
Addressed a Campus Wire issue: an autograder roll-up bug reset a grid score to zero; the repository problem is resolved. A new explanatory post was recommended.

Compared kernel vs. user-level threads and hybrid approaches for scaling to very large numbers of threads.
Current implementations are not optimal but offer trade-offs.
Explained wait:
Iterates over processes to locate exited children.
Copies exit state to the parent, frees resources, and completes cleanup.

Introduced two new syscalls:
sys_track_self to enable metrics for the current process via a track Boolean in proc.
sys_track_wait to wait on a tracked child and retrieve its metrics.
Workflow example: track ls runs ls with tracking enabled; the kernel records per-syscall and memory metrics for later retrieval.

Tracking includes:
Per-syscall counts, bytes read/written.
Memory layout (text, stack, heap).
Page table/page counts and related memory stats.
Implementation spans kernel and user space:
Kernel collects and stores metrics; sys_track_wait copies them out to user space.
The user-level track tool formats and prints results.
Recommended an incremental approach guided by the detailed project specification indicating exact integration points.