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.
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:
user_none()
- A dummy syscall that goes to the O/S kernel,
does nothing, and comes back.
user_yield()
- Allows the current running process to yield the
processor, inviting the O/S to reschedule another process to run, if
conditiions permit.
user_getc()
- Fetches a character from a hardware input
device. By default, device '0' will be your existing synchronous serial
port driver.
user_putc()
- Writes a character to a hardware output device.
By default, device '0' will be your existing synchronous serial port
driver.
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.
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.
[Revised 2020 Sep 23 02:42 DWB]