The aim of this milestone is to design the RPC protocol for the
system call interface. You should implement both the client and
system side of this interface. This client side system call
interface must conform to the interface provided in libs/sel4/libsos/include
.
You should create a sos.c
that implements the sos.h interface within the library.
At this stage you will not actually be able to implement most
of the system calls, however you should be able to partially
implement open/close, read/write
for the
console
device. You should also be able to implement sleep
, time_stamp
and process_wait
, which only needs to work for the console. In other words,
you need to modify your timer driver to be able to sleep and wake up sosh.
This will allow you to run a simple
shell on your system, which will allow you to perform interactive
testing.
You should also change the implementation of sys_morecore
in
libs/sel4/libsos/src/sys_morecore.c
to be backed by your own
system call to the rootserver, in order to fetch more memory for malloc.
Other system calls should output system call not
implemented
.
When a program opens the file console
it should
access the console on the serial device. The console is a multiple
writer, single reader device, i.e., more than one process can
concurrently open the device for writing, but only one process can
open the device for reading.
Reading the console is a blocking operation. If a process reads from the console and there is no data available it should block until data becomes available.
Be careful not to implement the console device as a 'hack'. You should think about being able to support multiple serial ports and other stream devices in your design (although not necessarily implement them). This means designing a consistent interface for interacting with all devices. You may want to read up on how Linux treats devices.
You may once again find the documentation on libserial handy.
You will need to modify the libsos library to add implementations
of the interface defined in libs/sel4/libsos/include/sos.h
.
You will also need to add sosh to the applications that are being built and included in the dite. Change the following lines in the top level Makefile:
from: sos-package: om_server sos elfloader common kernel_elf dite tty_test to: sos-package: om_server sos elfloader common kernel_elf dite sosh
from: dite -D 0 ${STAGE_BASE}/bin/sos -o ${STAGE_BASE}/bin/temp/sos -R ${STAGE_BASE}/bin/tty_test to: dite -D 0 ${STAGE_BASE}/bin/sos -o ${STAGE_BASE}/bin/temp/sos -R ${STAGE_BASE}/bin/sosh
You should copy the contents of tty_test/ttyout.c to libs/sel4/libsos/src.
At this stage of the project you will need to decide whether you want to have a simple single-threaded server, or to multi-thread it. A multi-threaded design could be advantageous to deal with the inherent concurrency your system will have (e.g. between paging, system calls, asynchronous I/O and clock interrupts), but it will require careful design of synchronisation in order to avoid race conditions and deadlocks. A single threaded model will require extra attention to ensure liveness.
Another design descision is how to transfer data between the kernel and user processes. Some options you have are:
memcpy
data into it when you need to
transfer data.Whatever you do, remember the basic engineering rule: keep it simple, stupid!(KISS).
This milestone is larger than it seems. The system call interface of an OS determines how user applications receive data they request. You will need to consider how you can move data in various quantities between your root server and clients. Scenarios to consider include:
Think about how your OS/161 did it. Was it copy-in-copy-out? Did it reach into application address spaces based on app-supplied pointers? If so, what are the implications of this approach in the face of paging? (That is, what happens if the app's buffer has been paged out? How do you arrange to block the syscall, page the relevant data back in, and then restart the syscall?)
For this assessment you should be able to demonstrate
sosh
running, and SOS outputting system
call not implemented
for the relevant system calls.
sosh
makes use of the SOS system calls in its
ls
and ps
commands. This should be
sufficient to demonstrate that your system calls work. Of course,
you can also write your own test code.
You should also show some user level test code that uses the
time_stamp
and sleep
system calls. You
may find it useful to extend sosh
to have a
time
and sleep
command. The
sleep
implemention must use your
clock driver.
As always, you should be able to explain both the design and your implementation.
Note: In line with the comments in the advice section, streaming large blocks of data over multiple IPCs is a sure-fire way not to get full marks!