When working on OS161 system calls, you'll probably see a bunch of this error, especially you haven't implemented _exit syscall and try to do some basic user programs, e.g., p /bin/true.

Note, this problem has been fixed in OS/161 version 1.99.07.

When you finished the process system call (e.g., fork, execv) and test your system call by executing some user program, you'll probably find that the console input behavior is messed up.

If you're not familiar with sbrk system call, here is it's wiki, and its interface description. In a nutshell, malloc will use sbrk to get heap space.

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.

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.