OS161: Arguments Passing in System Call

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.

more ...

OS161 Process Scheduling

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.

more ...

OS161 File Operation Overview

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.

more ...

OS161 pid Management

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.

more ...

OS161 execv System Call

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
more ...