Here are various documents that I found helpful for implementing OS161 virtual memory system.

One principle of kernel programming is that: do not trust anything users passed in. Since we assume that users are bad, they will do anything they can to crash the kernel (just as $OS161_SRC/user/testbin/badcall/badcall.c do). So we need pay special attention to the arguments of the system calls, especially the pointers.

Here are some practice that will hopefully make you feel more comfortable and more productive when you poking around with os161 syscalls.

Let's use the fork system call as an example. For convinience, let's assume $OS161_SRC is your os161 source root directory.

OS161 provides a simple round-robin scheduler by default. It works like this:

• hardclock from $OS161_SRC/kern/thread/clock.c will be periodically called (from hardware clock interrupt handler)

• Two functions may be called there after:

  • schedule to change the order the threads in ready queue, which currently does nothing
  • thread_consider_migraton to enable thread migration among CPU cores

• Then it will call thread_yield to cause the current thread yield to another thread

We need to play with the schedule function to give interactive threads higher priority.

Assume you've read my previous post on file operations in OS161, then everything is quite straightforward. One more thing, remember to protect every access to the file descriptor data structure using lock!

Let's get started.

In user space, when open a file, user program will get a file descriptor (a integer) that represent that file. User can use this descriptor to perform various operations on this file: read, write, seek, etc. As I see it, this design is quite clean in that:

• Hide most of the details from user, for both safety and simplicity

• Enable more high level abstraction: everything (socket, pipe..) is a file

The file descriptor is actually an index to kernel space structure that contains all the details of opened files. So at kernel side, we need to do a lot bookkeeping stuff.

Before going on, assume you've read my previous post on pid management

Thanks to the struct process, our work is much simplified. Quoting Eric S.Raymond here.

Smart data structures and dumb code works a lot better than the other way around.

There are many way to manage each process's pid. Here is the way I do it.

I decided to make minimal modification to $OS161_SRC/kern/thread/thread.c, in case anything is ruined. So I only add two things to the thread module. One is I add a t_pid field to struct thread so that getpid system call is trivial. Another is I add a call of pid_alloc in thread_alloc to initialize new thread's t_pid. That's it. No more touch on the thread module.

Basically, execv do more or less the same thing with runprogram in $OS161_SRC/kern/syscall/runprogram.c. The overall flow of sys_execv are:

1. Copy arguments from user space into kernel buffer
2. Open the executable, create a new address space and load the elf into it
3. Copy the arguments from kernel buffer into user stack
4. Return user mode using enter_new_process