Changelog:

Your task

  1. Obtain a copy of a VM or another Linux environment (most likely not OS X, see below) with:
    • a working C and C++ compiler
    • a recent copy of qemu installed (configured to support full 32-bit x86 emulation).

    We have supplied a suitable VM image here (login with username ‘user’, password ‘password; use with virtaulbox), or you can use your own.

  2. Download and get xv6 to boot in an emulated machine. For how to do this, see the instructions below. Run it and make sure you can run some simple commands in a shell in the emulated machine.

  3. Add a new system call writecount() that takes no arguments and returns the number of times the write system call has been called across all processes. See below for hints about how to do this.

    We do not care how your writecount() system call counts calls to write that fail, such as from having invalid arguments. We also don’t care how it treats simulataneous calls to write() and/or writecount().

  4. Write a program that uses and tests this new system call. See below for hints on how to do this.

  5. Run make submit to create a .tar.gz archive and upload it to the 4414-001 submission site.

Hints

Getting xv6 running

  1. Download our version of xv6 using git: git clone https://github.com/uva-reiss-cs4414/xv6.git

  2. In the newly created xv6 directory, run make.

  3. Boot xv6 in an emulator using one of the following methods:

    • To boot the OS in an emulator with a graphical user interface, run make qemu.

    • To boot the OS in an emulator without a graphical user interface, run make qemu-nox. (nox probably standards for “no X”; X is short for the X windowing system, the primary graphics system on Unix-like operating systems.)

Adding the system call

For this task, you might want to read

Basic steps for adding system calls:

  1. Create a sys_writecount function based on an existing simple system call function like sys_uptime. (For this assignment, you do not need to (but are allowed to) use a spinlock and acquire or release like uptime does since we do not care how your code works with multiple processors.)

  2. Add a system call number for your new system call to syscall.h.

  3. Add your sys_writecount to the table in syscall.c.

  4. Edit sys_write. You can use a command like grep sys_write *.c to find out where it is.

  5. Edit usys.S and user.h to create a system call wrapper function that invokes your system call from a normal user program.

Testing your system call

  1. Using echo.c as a template, create a new program to run your writecount system call and print the results.

  2. Edit Makefile by adding your program to UPROGS, similar to how echo is included on this list.

  3. Run make and then make qemu to boot the OS with your new program included.

  4. If your test program crashes after finishing, you may have forgotten to exit() at the end. (Returning from main() will not work.)

  5. You could run other programs that call write() (e.g. by outputting anything to the console) and/or have your test program make writes (using the write() system call wrapping function directly or by taking advantage of printf() calling write) to verify that the count make sense.

  6. In kernel code, you can do debug printing using the cprintf() function. You can use this to help debug any problems with your code, or get a better idea what’s going on.

Locks not required

  1. sys_uptime uses a spinlock, which it uses to handle the case where xv6 is running on multiple processors or when the system call is interrupted by a timer interrupt. For this assignment, we do not care if you handle this problem. (We will ensure only one process is calling write() at a time when testing.)

  2. An implementation of writecount that correctly handled multiple concurrent calls to write() and/or writecount() would probably use a spinlock around accesses to the counter (from both write and writecount).

xv6 book: note on terminology

CS 3330 and the xv6 book and source code use slightly different terminology related to exceptions:

CS 3330 Term most common xv6 term description
exception trap any event in which the processor transfers control from whatever program was running to the OS (to the “kernel”) at a location chosen by the OS
fault exception a program performs an illegal action, causing control to be transferred to the OS to decide what to do
interrupt interrupt an event external to the program, such as a timer or an input/output device needs the OS’s attention
trap (specific kind) trap an exception deliberately triggered by an instruction; on x86 this is via the int instruction

a note on GDB

  1. It is possible to use GDB with xv6. To do this instead of running make qemu or make qemu-nox, run make qemu-gdb or make qemu-nox-gdb respectively. Then, in another window, run gdb from the xv6 directory, and then run the command source .gdbinit within GDB. Then, within GDB, you can set breakpoints with break function_name (and various similar commands) and start execution of the OS with continue.

a note on OS X

Because xv6 expects ELF format binaries, xv6 will require a cross-compiler on OS X. We recommend (and will support) using a Linux environment instead (such as through a VM) instead, but if you can get it working natively on OS X using a cross-compiler, that’s great (and your fellow students would probably appreciate the information).

Credit

This assignment is based loosely on Arpaci-Dusseau’s initial-xv6 assignment.