​

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 code
    printf("parent: child=%d\n", pid);
    pid = wait((int *) 0);
    printf("child %d is done\n", pid);
} else if(pid == 0) {
    // Child code
    printf("child: exiting\n");
    exit(0);
} else {
    // Error
    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[1] = "hello";       // Argument
argv[2] = 0;             // NULL terminator
exec("/bin/echo", argv);
printf("exec error\n");  // Only prints if exec fails

[!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()
• Shell can modify child’s file descriptors before exec()
• Parent’s I/O remains unchanged

• Combined forkexec() call - awkward for I/O redirection
• Shell modifies own I/O, then undoes - error-prone
• Every program handles own redirection - duplicated work

​

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 doesn’t know if reading from file, console, or pipe
• cat doesn’t know if writing to file, console, or pipe
• Same code works for all cases
• Shell controls actual I/O sources/destinations

​

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);
if(fork() == 0) {
    // Child
    close(0);          // Close stdin
    dup(p[0]);         // stdin now reads from pipe
    close(p[0]);       // Close original pipe read fd
    close(p[1]);       // Close pipe write fd
    exec("/bin/wc", argv);
} else {
    // Parent
    close(p[0]);       // Close pipe read end
    write(p[1], "hello world\n", 12);
    close(p[1]);       // Signal EOF to child
}

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
2. Unlimited size - Not limited by disk space
3. Parallel execution - Both programs run simultaneously

1. Must manually clean up
2. Need disk space for all data
3. Sequential execution (first program must finish)

​

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

​

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.