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

If you're not already familiar with UNIX fork system call, here is it's function description and its entry on Wikipedia.

Basically, in sys_fork, we need to do the follow things:

1. Copy parent's trap frame, and pass it to child thread
2. Copy parent's address space
3. Create child thread (using thread_fork)
4. Copy parent's file table into child
5. Parent returns with child's pid immediately
6. Child returns with 0

So, let's get started.