In this assignment you will be implementing a set of file-related system calls. Upon completion, your operating system will be able to run a single application at user-level and perform some basic file I/O.

A substantial part of this assignment is understanding how OS/161 works and determining what code is required to implement the required functionality. Expect to spend at least as long browsing and digesting OS/161 code as actually writing and debugging your own code.

If you attempt the advanced part, you will add process related system calls and the ability to run multiple applications.

Your current OS/161 system has minimal support for running executables, nothing that could be considered a true process. Assignment 2 starts the transformation of OS/161 into something closer to a true operating system. After this assignment, it will be capable of running a process from actual compiled programs stored in your account. The program will be loaded into OS/161 and executed in user mode by System/161; this will occur under the control of your kernel. First, however, you must implement part of the interface between user-mode programs ("userland") and the kernel. As usual, we provide part of the code you will need. Your job is to design and build the missing pieces.

Our code can run one user-level C program at a time as long as it doesn't want to do anything but shut the system down. We have provided sample user programs that do this (reboot, halt, poweroff), as well as others that make use of features you might be adding in this and future assignments. So far, all the code you have written for OS/161 has only been run within, and only been used by, the operating system kernel. In a real operating system, the kernel's main function is to provide support for user-level programs. Most such support is accessed via "system calls." We give you one system call, reboot(), which is implemented in the function sys_reboot() in main.c. In GDB, if you put a breakpoint on sys_reboot and run the "reboot" program, you can use "backtrace" to see how it got there.

For those attempting the advanced version of the assignment, you will also be implementing the subsystem that keeps track of multiple tasks. You must decide what data structures you will need to hold the data pertinent to a "process" (hint: look at kernel include files of your favorite operating system for suggestions, specifically the proc structure.) The first step is to read and understand the parts of the system that we have written for you.

loadelf.c

runprogram.c

In the advanced assignment, runprogram() is a good base for writing the execv() system call, but only a base. When writing your design doc, you should determine what more is required for execv() that runprogram() does not need to worry about. Once you have design your process framework, runprogram() should be altered to start processes properly within this framework.

uio.c

Questions

1. What are the ELF magic numbers?

2. What is the difference between UIO_USERISPACE and UIO_USERSPACE? When should one use UIO_SYSSPACE instead?

3. Why can the struct uio that is used to read in a segment be allocated on the stack in load_segment() (i.e., where does the memory read actually go)?

4. In runprogram(), why is it important to call vfs_close before going to usermode?

5. What function forces the processor to switch into usermode? Is this function machine dependent?

6. In what file are copyin and copyout defined? memmove? Why can't copyin and copyout be implemented as simply as memmove?

7. What (briefly) is the purpose of userptr_t?

trap.c

syscall.c

Questions

8. What is the numerical value of the exception code for a MIPS system call?

9. Why does mips_trap() set curspl to SPL_HIGH "manually", instead of using splhigh()?

10. How many bytes is an instruction in MIPS? (Answer this by reading mips_syscall() carefully, not by looking somewhere else.)

11. What is the contents of the struct trapframe? Where the struct trapframe that is passed into mips_syscall stored?

12. What would be required to implement a system call that took more than 4 arguments?

13. What is the purpose of userptr_t?

errno.c

syscalls-mips.S

syscalls.S

Questions

14. What is the purpose of the SYSCALL macro?

15. What is the MIPS instruction that actually triggers a system call? (Answer this by reading the source in this directory, not looking somewhere else.)

Questions

16. How are vfs_open, vfs_close used? What other vfs_() calls are relevant?

17. What are VOP_READ, VOP_WRITE? How are they used?

18. What does VOP_TRYSEEK do?

19. Where is the struct thread defined? What does this structure contain?

fork()

Questions

20. What is the purpose of the fork() system call?

21. What process state is shared between the parent and child?

22. What process state is copied between the parent and child?

Obtaining and setting up ASST2 in SVN

% cd /home/cs3231/assigns
% svn import asst2/src file:///home/osprjXXX/repo/asst2/trunk -m "Initial import"

% svn copy -m "Tag initial import" file:///home/osprjXXX/repo/asst2/trunk
file:///home/osprjXXX/repo/asst2/initial

fork()

The amount of code to implement fork is quite small; the main challenge is to understand what needs to be done. We strongly encourage you to implement the file-related system calls first, with fork in mind.

Some hints:

• Find md_forkentry in have a look syscall.c. This is a stub where you will place your code to implement the fork system call.
• Read the comments above mips_usermode() in kern/arch/mips/mips/trap.c
• Read the comments in kern/include/addrspace.h, particularly as_copy.
• You will need to copy the trapframe from the parent to the child. You should be careful how you do this, as there is a possible race condition (where?/why?).
• You may wish to base your implementation on the thread_fork() function in kern/thread/thread.c.

getpid()

A pid, or process ID, is a unique number that identifies a process. The implementation of getpid() is not terribly challenging, but pid allocation and reclamation are the important concepts that you must implement. It is not OK for your system to crash because over the lifetime of its execution you've used up all the pids. Design your pid system; implement all the tasks associated with pid maintenance, and only then implement getpid(). When your pid system is working correctly, change your fork implementation to return the child's pid to the parent, rather than 1.

execv(), waitpid(), _exit()

Although it may seem simple at first, waitpid() requires a fair bit of design. Read the specification carefully to understand the semantics, and consider these semantics from the ground up in your design. You may also wish to consult the UNIX man page, though keep in mind that you are not required to implement all the things UNIX waitpid() supports, nor is the UNIX parent/child model of waiting the only valid or viable possibility. The implementation of _exit() is intimately connected to the implementation of waitpid(). They are essentially two halves of the same mechanism. Most of the time, the code for _exit() will be simple and the code for waitpid() relatively complicated, but it's perfectly viable to design it the other way around as well. If you find both are becoming extremely complicated, it may be a sign that you should rethink your design.

kill_curthread()

Write and test a simple user shell

Your shell should also support the basic job control function: &, which executes a process in the background. That is, a prompt appears, allowing the user to enter another command, even before the last command has finished executing. Your shell should not waste an excessive amount of space remembering exit codes if you run a lot of jobs in the background. The skeleton for your shell is in bin/sh/sh.c. Since the OS/161 system calls needed by your shell are remarkably similar to those supported by Linux, you should be able to write your shell and test it by compiling for Linux. (The supplied makefile already does this.) This way, you can write your shell before the rest of Assignment 2 is finished. Keep in mind that this is the same shell you will use later as the user interface for OS/161; it must run as a user program and leave sufficient space for other user programs to run. Consequently, be careful to keep your shell lean. Avoid adding the ultimate X-interface you've always wanted to have; however, it must include the following built-in commands: cd exit

Test your shell.

char *filename = "/bin/cp";
char *args[4];
pid_t pid;
args[0] = "cp";
args[1] = "file1";
args[2] = "file2";
args[3] = NULL;
pid = fork();
if (pid == 0)
execv(filename, argv);

Some questions to think about:

Passing arguments from one user program, through the kernel, into another user program, is a bit of a chore. What form does this take in C? This is rather tricky, and there are many ways to be led astray. You will probably find that very detailed pictures and several walk-throughs will be most helpful.

How will you determine: (a) the stack pointer initial value; (b) the initial register contents; (c) the return value; (d) whether you can exec the program at all?

What new data structures will you need to manage multiple processes?

What relationships do these new structures have with the rest of the system?

How will you manage file accesses? When your shell invokes the cat command, and the cat command starts to read file1, what will happen if the shell also tries to read file1? What would you like to happen?

How you will keep track of running processes. For which system calls is this useful?

How you will implement the execv system call. How is the argument passing in this function different from that of other system calls?

What functionality your shell should have.