CS 631-01 Systems Foundations — Meeting Summary¶
Date: Apr 23, 2026
Time: 08:12 AM Pacific Time (US and Canada)
Meeting ID: 870 0988 0761
Quick Recap¶
- Greg delivered a comprehensive lecture on operating systems design, focusing on the final topic of the semester: implementing an OS using Oktox, a Rust reimplementation of the xv6 teaching operating system.
- Core concepts covered:
- System calls and the user–kernel boundary
- User-level processes vs. programs
- Unix file descriptors as a unified I/O abstraction (console, files, pipes)
- Demonstrations included Rust code that:
- Counts file bytes using read
- Writes text to files using write and open
- He explained how system calls transfer control from user mode to kernel mode via RISC-V ecall, and reviewed the Oktox source structure and how user programs interact with the kernel.
Next Steps¶
Instructor (Greg)¶
- Send the lab project assignment (add/modify/create user-level programs demonstrating system calls) by next week.
- Send a lightweight lab project by the end of next week.
Collaboration (Students)¶
- Complete the assigned lab project (user-level programs using system calls) by the end of next week.
- Review the guide and run the provided example programs as preparation for the lab.
Detailed Summary¶
1) Operating Systems Design Overview¶
- The session introduced the final course topic: OS design and implementation using Oktox (a Rust-based system modeled after xv6).
- Focus areas:
- User-level systems
- System calls and the system call interface
- Examples will be shared via a public repository on campus.
- Course goals include building intuition for OS complexity; networking is out of scope for this class.
2) Lab Project and Computer Architecture Overview¶
- Planned lab work:
- Write user-level programs
- Make kernel modifications
- Extend system calls
- Architecture context:
- The OS is loaded into RAM from persistent storage at boot.
- The kernel manages memory and disk via the file system.
- The relationship between CPU, RAM, and disk was reviewed, including how the kernel is loaded on power-on.
3) Operating System Fundamentals¶
- The OS is the first program loaded at boot and serves as a resource manager for devices, memory, and files.
- It provides hardware abstractions via system calls.
- Modern OSes manage multiple concurrent processes, creating the illusion of separate CPUs while coordinating shared resources.
4) Operating Systems and the C Language¶
- Historical context: OS evolution and the development of C enabled efficient, portable systems.
- Protection domains were introduced:
- Kernel code vs. user processes
- Initially described on a single core, with plans to discuss multi-core later.
5) RISC-V Bare-Metal Kernel Demo (Oktox)¶
- Oktox runs in QEMU and provides:
- Process management
- Memory management
- A file system
- The kernel operates reactively after boot by launching the first process and serving user programs.
- Two primary communication mechanisms between user processes and the kernel were introduced; discussion was cut off before both were detailed.
6) System Calls and Process Concepts¶
- System calls enable user processes to request kernel services.
- Highlighted calls (Oktox/xv6-style):
- Process: fork, exec
- I/O and IPC: read, write, open, pipe
- Memory-related calls (overview)
- Programs vs. processes:
- Programs are static, compiled artifacts.
- Processes are executing instances with virtual/physical memory (code, data, stack).
7) Unix File Descriptors and Processes¶
- File descriptors unify I/O across devices (console, files, pipes) via the same system calls.
- Process creation model:
- fork creates a child process
- exec replaces a process’s image with a new program
- Privilege separation:
- User mode has restricted access and cannot directly access hardware or other processes’ memory.
- Kernel mode executes privileged operations.
8) System Call Interface¶
- The user–kernel transition on RISC-V uses ecall.
- On transition:
- Privilege level changes
- Memory visibility and access validations occur
- Process Control Blocks (PCBs) track process state.
- Default file descriptors:
- 0: stdin
- 1: stdout
- 2: stderr
9) Rust, File Descriptors, and System Calls¶
- File descriptors act as numeric handles recognized by both user space and the kernel.
- Examples included writing to the screen and files via system calls.
- Plans include:
- Extending a shell implementation
- Writing user programs that exercise system calls
10) Rust System Calls Structure¶
- Source organization separates kernel code and user programs.
- All required Rust crates are included in the source tree.
- User programs can:
- Invoke system calls directly
- Or use a convenience library
- The kernel sets up argv for user programs at exec time.
11) Mini Word Count Demo (Rust)¶
- A simple byte-counting program:
- Accepts a filename as an argument
- Uses open and read to process the file
- Demonstrates reading into a buffer and maintaining a running count
- Differences from C:
- Rust often carries length metadata with slices/structures, whereas C requires explicit length parameters.
12) Rust vs. C Buffer Handling¶
- read returns the actual number of bytes read; 0 indicates EOF.
- Demonstrated reading in fixed-size chunks (e.g., 512 bytes).
- Importance of closing file descriptors to avoid exhausting kernel resources, especially in long-running programs.
13) Kernel Crossing Mechanism for System Calls¶
- Buffer passing considerations:
- The kernel needs a pointer and a length to safely access user buffers.
- Rust types (e.g., slices) encapsulate pointer+length in user space; the syscall interface passes these as explicit parameters.
- Performance guidance:
- Avoid one-byte reads/writes due to syscall overhead.
- Use reasonable buffer sizes.
- Partial reads are normal, particularly for sockets and other non-blocking I/O.
14) Writing Files on Unix¶
- Workflow:
- open to obtain a file descriptor
- write to send bytes from a buffer
- Check return values to handle short writes
- Maintain offsets for continuous writing (or rely on the OS file offset)
- A lightweight lab is planned for the end of next week, with a focus on decoder and processor components; students are encouraged to ask questions as they proceed.
End of summary.