Project #5: Trap Handlers

Submit: Turn in your xtrap.c and testcases.c source files using the turnin command on morbius.mscsnet.mu.edu or one of the other Systems Lab machines.

Work should be completed in pairs. Be certain to include both names in the comment block at the top of all submitted source code files. It would be courteous to confirm with your partner when submitting the assignment. You may modify any files in the operating system, but only changes to xtrap.c and testcases.c will be graded for this assignment.

It's a Trap!

Preparation

First, make a copy of your Project 4 directory:
    cp -R xinu-hw4 xinu-hw5
Then, untar the new project files on top of it:
    tar xvzf ~brylow/os/Projects/xinu-hw5.tgz

New files:

system/start.S   Updated O/S start with exception handlers in place.
system/irq_handler.S   ARM assembly code for managing exceptions -- calls xtrap().
system/xtrap.c   Default Xinu Trap Handler catches exceptions and calls other specific dispatchers.
system/dispatch.c   Dispatcher for hardware interrupt request (IRQs), called from xtrap(). We'll expand on this in later assignments.
system/syscall_dispatch.c   A simple system call interface, plus stubs for several simple user and kernel syscall components. You must call this from xtrap().
include/syscall.h   New header with syscall definitions, structures and prototypes.

The xtrap() currently function defaults to treating the SWI (Software Interrupt) instruction as a generic, show-stopping hardware exception. You must add the intelligence to recognize when the exception is caused by a deliberate System Call from a "user" process in to the "kernel", and collect the system state information necessary for syscall_dispatch() to do its work.

To begin, we'll start with just four simple syscalls:

Our current simple embedded O/S does not yet provide memory protection, nor does it yet execute user processes in a more restricted processor protection mode. As a result, our system call interface will only provide the first of three required components for protecting the O/S from user processes. Your user processes will still be able to call arbitrary internal kernel functions without going through the system call interface, and read or write data from other processes or the O/S itself.

As we add more features to our O/S in weeks to come, we will create the memory virtualization abstractions that will prevent user code from accessing O/S functions and data without going through an approved user_* system call function. For now, we're building system calls even though all of our processes are still executing at the "kernel" privilege level, with unrestricted view of all memory.

 

Testing

The default test cases provided with the tarball exercise each one of our starting system calls at least once. Judicious use of additional debugging kprintf() calls will be essential for debugging your system call interface as you build it. Be certain to comment out these debugging statements when you turn in your code each night, lest TA-Bot find your code unworthy.

Once you have the basics working, consider filling in some of the other system call stubs left for future expansion, or write a version of user_printf() that processes all of the format string in the user process, but relies on the user_putc() syscall for requesting that the O/S output each resulting character.

This project can be completed in fewer than a dozen lines of code, but the technical details of the system call can be quite complex and hard to keep straight. It is very unlikely that random code snippets from the Internet will help to solve this one -- it is essential that you understand the data structures and mechanisms involved, and reason through an adequate design to solve the problem.

Admiral Gial Ackbar

[back]

[Revised 2020 Sep 23 02:42 DWB]