Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Operating System Interfaces - Complete Study Guide

​

Core Concept: What is an Operating System?

​

Key Design Tension

[!IMPORTANT] The Interface Dilemma

• Simple/narrow interface = easier to implement correctly, but limited features
• Complex interface = more features but harder to maintain and secure
• Solution: Few powerful mechanisms that combine for generality

​

The xv6 Operating System

​

What is xv6?

• Small enough to understand completely (~9,000 lines)
• Real enough to be useful (actual working OS)
• Provides essential Unix interfaces
• Runs on RISC-V architecture

​

Architecture Overview

• Process: Running program with memory (instructions, data, stack)
• Kernel: Special program providing services to processes
• System Call: Process requests kernel service (e.g., fork(), open(), read())
• User Space: Normal programs run here (limited privileges)
• Kernel Space: Kernel runs here (full hardware access)

​

System Calls Reference

​

Process Management

​

File Operations

​

File System

[!NOTE] Convention: Unless stated otherwise, system calls return 0 for success and -1 for error.

​

Processes and Memory

​

Process Structure

• User-space memory: instructions + data + stack
• Kernel-private state: CPU registers, PID, etc.
• PID: Process identifier (unique number)

​

fork() - Creating Processes

1. Creates exact copy of parent process memory
2. Both processes continue execution after fork()
3. Only difference: return value

• Parent gets: child’s PID (positive number)
• Child gets: 0
• Error: -1

int pid = fork();
if(pid > 0) {
    // Parent branch: fork() returned the child's PID (a positive number).
    // The parent continues executing from this point with its own copy of memory.
    printf("parent: child=%d\n", pid);
    pid = wait((int *) 0);  // Block until the child calls exit()
    printf("child %d is done\n", pid);
} else if(pid == 0) {
    // Child branch: fork() returned 0, which is how the child knows it IS the child.
    // This code runs in a completely separate process with its own address space.
    printf("child: exiting\n");
    exit(0);
} else {
    // fork() returned -1: the kernel could not allocate a new process
    // (e.g., out of memory or process table full).
    printf("fork error\n");
}

parent: child=1234
child: exiting

child: exiting
parent: child=1234

parent: child 1234 is done

[!IMPORTANT] Critical Points:

• Parent and child have SEPARATE memory
• Changing variable in one doesn’t affect other
• Both start with identical memory contents
• Each has separate registers

​

wait() - Synchronizing Processes

• Returns PID of exited child
• Copies child’s exit status to provided address
• If no children exited yet, blocks until one does
• If no children exist, returns -1 immediately

int status;
int pid = wait(&status);  // Get exit status
// OR
int pid = wait(0);        // Don't care about status

​

exec() - Running Programs

[!WARNING] Critical characteristic: Does NOT create new process, replaces current one!

1. Path to executable file
2. Array of string arguments (NULL-terminated)

• Loads new program from file
• Replaces process memory completely
• Preserves: PID, file descriptors, open files
• If successful: NEVER returns (new program runs)
• If error: returns to caller

char *argv[3];
argv[0] = "echo";        // Program name (convention: argv[0] is the program name)
argv[1] = "hello";       // First real argument passed to the program
argv[2] = 0;             // NULL terminator -- exec() needs this to know where the array ends
exec("/bin/echo", argv); // Replaces this process's memory with /bin/echo's code
printf("exec error\n");  // This line only executes if exec() FAILED (returned -1).
                         // On success, the process is now running /bin/echo --
                         // the old code, stack, and heap are gone.

[!NOTE] argv[0] convention: First argument is program name (mostly ignored by program)

​

How Shell Uses These Calls

// Simplified shell structure
while(getcmd(buf, sizeof(buf)) >= 0) {
    if(fork() == 0) {
        // Child: run command
        runcmd(parsecmd(buf));
    }
    // Parent: wait for child
    wait(0);
}

1. Shell forks
2. Parent waits
3. Child calls exec("/bin/echo", ["echo", "hello", 0])
4. echo runs and calls exit()
5. Parent’s wait() returns
6. Shell ready for next command

• Allows I/O redirection between fork() and exec(). The child can close, open, and dup file descriptors in the gap between fork and exec, customizing its I/O environment without affecting the parent.
• Shell can modify child’s file descriptors before exec()
• Parent’s I/O remains unchanged

• Combined forkexec() call — awkward for I/O redirection because you would need to pass the full fd configuration as parameters
• Shell modifies own I/O, then undoes — error-prone and not thread-safe
• Every program handles own redirection — duplicated work across every utility

​

Memory Management

• fork() - Allocates memory for child’s copy
• exec() - Allocates memory for new executable

• sbrk(n) - Grow data memory by n bytes
• Returns location of new memory
• Used by malloc() implementation

• fork() uses copy-on-write (COW)
• Doesn’t actually copy memory until modified
• Avoids waste when exec() immediately follows fork()

​

I/O and File Descriptors

​

File Descriptor Concept

• Regular files
• Directories
• Devices (keyboard, screen, etc.)
• Pipes

• Open file/directory/device
• Create pipe
• Duplicate existing descriptor

​

File Descriptor Table

• Each process has private fd space
• FDs start at 0
• Kernel uses fd as index into table

• FD 0 = standard input (stdin)
• FD 1 = standard output (stdout)
• FD 2 = standard error (stderr)

​

read() and write()

• Reads UP TO n bytes from fd
• Copies into buf
• Returns number of bytes actually read
• Returns 0 at end of file
• Each fd has file offset that advances automatically

• Writes n bytes from buf to fd
• Returns number of bytes written
• Less than n only on error
• Offset advances automatically

// First read gets bytes 0-99
read(fd, buf, 100);
// Next read gets bytes 100-199
read(fd, buf, 100);

​

cat Example - The Power of Abstraction

char buf[512];
int n;
for(;;) {
    n = read(0, buf, sizeof buf);  // Read from stdin
    if(n == 0)
        break;                      // EOF
    if(n < 0) {
        fprintf(2, "read error\n"); // Error to stderr
        exit(1);
    }
    if(write(1, buf, n) != n) {     // Write to stdout
        fprintf(2, "write error\n");
        exit(1);
    }
}

• cat does not know if it is reading from a file, the console, or a pipe
• cat does not know if it is writing to a file, the console, or a pipe
• Same code works for all cases — this is the Unix “everything is a file” philosophy in action
• Shell controls actual I/O sources/destinations via fd manipulation

cat file.txt           # read from file, write to console
cat < input.txt        # read from redirected stdin
echo hello | cat       # read from pipe
cat > output.txt       # write to file instead of console
cat < in.txt | sort > out.txt  # pipe chain with redirection

​

File Descriptor Allocation

• Releases file descriptor
• Makes fd available for reuse

• Always uses LOWEST unused number
• This is critical for I/O redirection

​

I/O Redirection Mechanism

char *argv[2];
argv[0] = "cat";
argv[1] = 0;

if(fork() == 0) {
    close(0);                      // Free fd 0
    open("input.txt", O_RDONLY);   // Gets fd 0 (lowest available)
    exec("cat", argv);             // cat reads from fd 0
}

1. Child closes stdin (fd 0)
2. open() gets fd 0 (lowest available)
3. exec() preserves file descriptor table
4. cat reads from fd 0, which now refers to input.txt

​

open() Flags

• O_RDONLY - Read only
• O_WRONLY - Write only
• O_RDWR - Read and write
• O_CREATE - Create if doesn’t exist
• O_TRUNC - Truncate to zero length

fd = open("file", O_CREATE|O_WRONLY);

​

fork() and File Descriptors

if(fork() == 0) {
    write(1, "hello ", 6);
    exit(0);
} else {
    wait(0);
    write(1, "world\n", 6);
}

• Child writes "hello " at position 0
• Offset advances to 6
• Parent writes "world\n" at position 6

(echo hello; echo world) > output.txt

​

dup() - Duplicating Descriptors

• Returns new fd (lowest available)
• Both fds share offset (like fork())

fd = dup(1);
write(1, "hello ", 6);
write(fd, "world\n", 6);

• Derived from same original fd by fork()/dup()

• Separate open() calls, even for same file

​

Error Redirection

• > tmp1 - Redirect stdout (fd 1) to tmp1
• 2>&1 - Redirect stderr (fd 2) to duplicate of fd 1

close(1);
open("tmp1", O_CREATE|O_WRONLY);  // Gets fd 1
close(2);
dup(1);                            // Gets fd 2, refers to tmp1

​

Pipes

​

Pipe Concept

• One fd for reading
• One fd for writing

int p[2];
pipe(p);
// p[0] = read end
// p[1] = write end

​

Pipe Example - Running wc

int p[2];
char *argv[2];
argv[0] = "wc";
argv[1] = 0;

pipe(p);              // Create the pipe: p[0]=read end, p[1]=write end
if(fork() == 0) {
    // Child -- will become `wc`, reading from the pipe
    close(0);          // Free fd 0 (stdin) so the next open/dup gets it
    dup(p[0]);         // Duplicate pipe read end -> gets fd 0 (stdin)
    close(p[0]);       // Close the original pipe read fd (now redundant)
    close(p[1]);       // CRITICAL: close write end so wc will see EOF
    exec("/bin/wc", argv);  // wc reads from fd 0, which is now the pipe
} else {
    // Parent -- writes data into the pipe
    close(p[0]);       // Close read end (parent won't read from pipe)
    write(p[1], "hello world\n", 12);  // Send data to child
    close(p[1]);       // Close write end -> triggers EOF on read end
}

1. Parent creates pipe
2. Fork creates child with copy of pipe fds
3. Child redirects stdin to pipe read end
4. Child closes both pipe fds (already has copy at fd 0)
5. Parent closes read end (won’t read)
6. Parent writes data to pipe
7. Parent closes write end (signals EOF)
8. Child reads from stdin (pipe), processes, exits

[!IMPORTANT] Critical: Why close pipe fds?

• Child must close write end before exec()
• Otherwise wc would never see EOF (it has write end open)
• If ANY process has write end open, read won’t return EOF

​

Pipe Blocking Behavior

• If data available: returns data
• If no data AND write end open: blocks (waits for data)
• If no data AND all write ends closed: returns 0 (EOF)

​

Shell Pipeline Implementation

        shell
          |
          v
      pipe process
       /     \
      /       \
   grep      wc

1. Create pipe
2. Fork for grep
   • Redirect stdout to pipe write end
   • exec grep
3. Fork for wc
   • Redirect stdin to pipe read end
   • exec wc
4. Wait for both children

         shell
           |
       process1
        /    \
       a   process2
            /    \
           b      c

• Leaves = commands
• Interior nodes = processes managing pipes

​

Pipes vs Temporary Files

# With pipe
echo hello world | wc

# With temp file
echo hello world > /tmp/xyz; wc < /tmp/xyz

1. Auto cleanup — No temp files to delete; the pipe buffer is reclaimed when both ends close
2. Streaming — The writer does not need to finish before the reader starts. Data flows through the pipe in a FIFO stream, bounded by a kernel buffer (typically 64 KB on Linux). If the buffer is full, the writer blocks until the reader drains some data.
3. Parallel execution — Both programs run simultaneously, overlapping CPU and I/O work. grep can start processing output from find while find is still traversing directories.
4. Backpressure — If the consumer is slow, the pipe buffer fills up and the producer naturally pauses. This prevents unbounded memory growth without any explicit coordination.

1. Must manually clean up (and handle cleanup on errors/crashes)
2. Need disk space for all data — a pipeline processing 10 TB would require 10 TB of temp storage
3. Sequential execution (first program must finish before second starts)
4. Security risk: temp files can be read by other processes unless permissions are carefully managed

​

File System

​

Structure

• Tree of directories
• Root directory: /
• Data files: uninterpreted byte arrays
• Directories: named references to files/directories

• /a/b/c - Absolute path from root
• a/b/c - Relative to current directory

​

Directory Navigation

// Method 1
chdir("/a");
chdir("b");
open("c", O_RDONLY);

// Method 2
open("/a/b/c", O_RDONLY);

• Changes process current directory to /a, then /a/b
• Opens c relative to /a/b

• No directory change
• Direct absolute path

​

Creating Files and Directories

mkdir("/dir");                        // Create directory
fd = open("/dir/file", O_CREATE|O_WRONLY);  // Create file
close(fd);
mknod("/console", 1, 1);             // Create device file

• First number = major device number
• Second number = minor device number
• Together uniquely identify kernel device
• read()/write() calls diverted to device driver

​

Inodes and Links

• File type (file, directory, device)
• File length
• Location of content on disk
• Number of links to file

[!IMPORTANT] Key insight: File name ≠ file itself

• One inode can have multiple names (links)
• Each link is directory entry: name + inode reference

open("a", O_CREATE|O_WRONLY);
link("a", "b");

• One inode
• Two names: "a" and "b"
• Both refer to same content
• Reading/writing "a" = reading/writing "b"

​

stat Structure

struct stat {
    int dev;        // File system's disk device
    uint ino;       // Inode number (unique)
    short type;     // T_DIR, T_FILE, or T_DEVICE
    short nlink;    // Number of links to file
    uint64 size;    // Size in bytes
};

int fd = open("a", O_RDONLY);
struct stat st;
fstat(fd, &st);
printf("Inode: %d, Links: %d\n", st.ino, st.nlink);

• Both "a" and "b" have same ino
• nlink = 2

​

unlink() - Removing Names

• Removes name from file system
• Decrements link count
• Inode and disk space freed ONLY when:
  • Link count = 0 AND
  • No file descriptors refer to it

open("a", O_CREATE|O_WRONLY);
link("a", "b");
unlink("a");

• Name "a" removed
• File still accessible as "b"
• Inode unchanged

fd = open("/tmp/xyz", O_CREATE|O_RDWR);
unlink("/tmp/xyz");
// File has no name now
// Will be deleted when process closes fd or exits

​

Built-in vs External Commands

• mkdir
• ln
• rm
• ls
• cat
• Most commands

• Anyone can add new commands
• No need to modify kernel/shell
• Easier to extend system

• cd

// If cd was external:
if(fork() == 0) {
    // Child changes its own directory
    chdir("/new/dir");
    exit(0);
}
// Parent (shell) directory unchanged!

[!WARNING] Problem: cd must change SHELL’s directory, not child’s

​

System Call Flow

​

Tracing fork() from User to Kernel

// user/sh.c
int pid = fork();

.global fork
fork:
    li a7, SYS_fork    # a7 = system call number (1)
    ecall              # Trap into kernel!
    ret                # Return with result in a0

uservec:
    # Save user registers
    csrw sscratch, a0
    sd ra, 40(a0)
    sd sp, 48(a0)
    # ... save all 32 registers ...
    
    # Load kernel page table
    ld t1, 0(a0)
    csrw satp, t1
    sfence.vma zero, zero
    
    # Jump to usertrap() in C
    jr t0

void usertrap(void)
{
  struct proc *p = myproc();
  p->trapframe->epc = r_sepc();

  if(r_scause() == 8){
    // System call
    p->trapframe->epc += 4;   // Advance PC past ecall
    intr_on();
    syscall();                 // Handle the system call!
  }

  usertrapret();
}

void syscall(void)
{
  int num;
  struct proc *p = myproc();

  num = p->trapframe->a7;      // Get syscall number
  
  if(num > 0 && num < NELEM(syscalls) && syscalls[num]) {
    p->trapframe->a0 = syscalls[num]();  // Call handler
  } else {
    printf("%d %s: unknown sys call %d\n", p->pid, p->name, num);
    p->trapframe->a0 = -1;
  }
}

int fork(void)
{
  struct proc *np;
  struct proc *p = myproc();

  // Allocate process
  if((np = allocproc()) == 0)
    return -1;

  // Copy user memory from parent to child
  if(uvmcopy(p->pagetable, np->pagetable, p->sz) < 0){
    freeproc(np);
    return -1;
  }
  np->sz = p->sz;

  // Copy saved user registers
  *(np->trapframe) = *(p->trapframe);
  np->trapframe->a0 = 0;  // Child returns 0

  // Copy open file descriptors
  for(int i = 0; i < NOFILE; i++)
    if(p->ofile[i])
      np->ofile[i] = filedup(p->ofile[i]);

  np->state = RUNNABLE;
  return np->pid;  // Parent returns child's PID
}

​

Real World Context

​

Unix Philosophy

• Small programs doing one thing well
• Combine via pipes
• Shell as “scripting language”

• Standard file descriptors (0, 1, 2)
• Pipes for composition
• Simple but powerful shell syntax

​

POSIX Standard

• xv6 NOT POSIX compliant
• Missing: lseek(), many other calls
• Different implementations of existing calls
• Goal: Simplicity for teaching

• Many more system calls
• Networking, windowing, threads
• Many device drivers
• Continuous evolution

​

Alternative Designs

• Extended “everything is a file” concept
• Applied to networks, graphics
• Most Unix systems didn’t follow

• Predecessor of Unix
• Files looked like memory
• Very different interface
• Complexity influenced Unix designers to simplify

• Different abstractions possible
• File descriptors not only solution
• Unix model proven very successful

​

xv6 Limitations

• All processes run as root
• No isolation between users
• Teaching-focused tradeoff

• Minimal system calls
• No networking
• No windowing
• Basic functionality only

​

Key Takeaways

​

Design Principles

​

Core Abstractions

1. Processes - Unit of execution with isolated memory
2. File descriptors - Unified I/O interface for files, pipes, devices
3. Pipes - Communication channels between processes
4. File system - Persistent storage hierarchy with inodes and links

​

Why These Abstractions Work

• Hide differences (files, pipes, devices)
• Enable I/O redirection
• Simple but powerful

• Enables I/O redirection
• Shell controls child environment
• Parent unaffected

• Clean inter-process communication
• Better than temp files
• Enable parallel execution

• Separate names from content
• Multiple names for same file
• Automatic cleanup when unused

​

Getting Started with xv6

​

Installation (Ubuntu/Debian)

# Install dependencies
sudo apt-get install git build-essential gdb-multiarch \
  qemu-system-misc gcc-riscv64-linux-gnu binutils-riscv64-linux-gnu 

# Clone xv6
git clone git://github.com/mit-pdos/xv6-riscv.git
cd xv6-riscv

# Build and run
make qemu

# You'll see xv6 boot and get a shell prompt:
$ 

​

First Commands to Try

$ ls              # List files
$ cat README      # Show file contents  
$ echo hello xv6  # Print text
$ grep the README # Search in file
$ wc README       # Word count
$ mkdir test      # Create directory
$ sh              # Start new shell

​

Caveats and Common Pitfalls

​

Interview Deep-Dive

​

Interview Relevance

​

Resources

​

Official Materials

• xv6 Book - Complete guide
• xv6 Source Code - GitHub repository
• MIT 6.S081 - OS Engineering course

​

Next Steps

[!TIP] Learning Path: Start by reading the xv6 book alongside the source code. Try modifying xv6 to add features or change behavior. This hands-on experience is invaluable for truly understanding operating systems.