In this exercise you will modify the xv6 kernel to print out a line for each system call invocation. It is enough to print the name of the system call and the return value; you don't need to print the system call arguments.
When you're done, you should see output like this when booting xv6:
... fork -> 2 exec -> 0 open -> 3 close -> 0 $write -> 1 write -> 1
That's init forking and execing sh, sh making sure only two file descriptors are open, and sh writing the $ prompt. (Note: the output of the shell and the system call trace are intermixed, because the shell uses the write syscall to print its output.)
Hint: modify the syscall() function in kernel/syscall.c.
Run the programs you wrote in the lab and inspect the system call trace. Are there many system calls? Which systems calls correspond to code in the applications you wrote above?
Optional: print the system call arguments.
For the alarm system call it will be important to understand RISC-V assembly. Since in later labs you will also read and write assembly, it is important that you familiarize yourself with RISC_V assembly.
Add a file user/call.c with the following content, modify the Makefile to add the program to the user programs, and compile (make fs.img). The Makefile also produces a binary and a readable assembly a version of the program in the file user/call.asm.
#include "kernel/param.h"
#include "kernel/types.h"
#include "kernel/stat.h"
#include "user/user.h"
int g(int x) {
return x+3;
}
int f(int x) {
return g(x);
}
void main(void) {
printf(1, "%d %d\n", f(8)+1, 13);
exit();
}
Read through call.asm and understand it. The instruction manual for RISC-V is in the doc directory (doc/riscv-spec-v2.2.pdf). Here are some questions that you should answer for yourself:
In this exercise you'll add a feature to xv6 that periodically alerts a process as it uses CPU time. This might be useful for compute-bound processes that want to limit how much CPU time they chew up, or for processes that want to compute but also want to take some periodic action. More generally, you'll be implementing a primitive form of user-level interrupt/fault handlers; you could use something similar to handle page faults in the application, for example.
You should add a new sigalarm(interval, handler) system call. If an application calls sigalarm(n, fn), then after every n "ticks" of CPU time that the program consumes, the kernel will cause application function fn to be called. When fn returns, the application will resume where it left off. A tick is a fairly arbitrary unit of time in xv6, determined by how often a hardware timer generates interrupts.
You should put the following example program in user/alarmtest.c: XXX Insert the final program here; maybe just give the code in the repo
#include "kernel/param.h"
#include "kernel/types.h"
#include "kernel/stat.h"
#include "kernel/riscv.h"
#include "user/user.h"
void test0();
void test1();
void periodic();
int
main(int argc, char *argv[])
{
test0();
test1();
exit();
}
void test0()
{
int i;
printf(1, "test0 start\n");
alarm(2, periodic);
for(i = 0; i < 1000*500000; i++){
if((i % 250000) == 0)
write(2, ".", 1);
}
alarm(0, 0);
printf(1, "test0 done\n");
}
void
periodic()
{
printf(1, "alarm!\n");
}
void __attribute__ ((noinline)) foo(int i, int *j) {
if((i % 2500000) == 0) {
write(2, ".", 1);
}
*j += 1;
}
void test1() {
int i;
int j;
printf(1, "test1 start\n");
j = 0;
alarm(2, periodic);
for(i = 0; i < 1000*500000; i++){
foo(i, &j);
}
if(i != j) {
printf(2, "i %d should = j %d\n", i, j);
exit();
}
printf(1, "test1 done\n");
}
The program calls sigalarm(2, periodic1) in test0 to
ask the kernel to force a call to periodic() every 2 ticks,
and then spins for a while. After you have implemented
the sigalarm() system call in the kernel,
alarmtest should produce output like this for test0:
Update output for final usertests.c
$ alarmtest alarmtest starting .....alarm! ....alarm! .....alarm! ......alarm! .....alarm! ....alarm! ....alarm! ......alarm! .....alarm! ...alarm! ...$
(If you only see one "alarm!", try increasing the number of iterations in alarmtest.c by 10x.)
The main challenge will be to arrange that the handler is invoked when the process's alarm interval expires. In your usertrap, when a process's alarm interval expires, you'll want to cause it to execute its handler. How can you do that? You will need to understand in details how system calls work (i.e., the code in kernel/trampoline.S and kernel/trap.c). Which register contains the address where systems calls return to?
Your solution will be few lines of code, but it will be tricky to write the right lines of code. Common failure scenarios are: the user program crashes or doesn't terminate. You can see the assembly code for the alarmtest program in alarmtest.asm, which will be handy for debugging.
To get started, the best strategy is to first pass test0, which will force you to handle the main challenge above. Here are some hints how to pass test0:
int sigalarm(int ticks, void (*handler)());
if(which_dev == 2) ...
make CPUS=1 qemu
Test0 doesn't tests whether the handler returns correctly to interrupted instruction in test0. If you didn't get this right, it is likely that test1 will fail (the program crashes or the program goes into an infinite loop).
A main challenge is to arrange that when the handler returns, it returns to the instruction where the program was interrupted. Which register contains the return address of a function? When the kernel receives an interrupt, which register contains the address of the interrupted instruction?
Your solution is likely to require you to save and restore registers---what registers do you need to save and restore to resume the interrupted code correctly? (Hint: it will be many). There are several ways to do this, but one convenient way is to add another system call sigreturn that the handler calls when it is done. Your job is to arrange that sigreturn returns to the interrupted code. Some hints:
Once you pass test0 and test1, run usertests to make sure you didn't break any other parts of the kernel.