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 interace. This client side system call
interface must conform to the interface provided in
include/sos.h
. You should create a
libsos.a
library that your applications can link
against.
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. This will allow you to run a simple
shell on your system, which will allow you to perform interactive
testing.
Other system call 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 that 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 carefult 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).
You may once again find the documentation on libserial handy.
You will want to change your Makefile
to make it
build both your libsos.a
and the provided
sosh
application.
To add a new library you should create a new directory in the
lib/
directory, and place any source files into
it. You will also need to create a file subdir.mk
to
tell make how to build your new library. Its format should be
self-evident from the subdir.mk files in other provided
libraries. Finally you should change the line:
LIBS := l4e c device serialto include your new library. E.g.:
LIBS := l4e c device serial sos
To make sure a new application gets compiled you should change
the APPS
in your makefile. You will most likely
want to remove the tty_test application from your
build. Building more than one application may require extra
makefile hacking on your part.
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.
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 previous ones, and it is advisable that you split the workload between the group.
For this assessment you should be able to demonstrate
sosh
running, and the SOS outputting system
call not implemented
for the relevant system calls.
sosh
makes use of the the SOS system calls in its
ls
and ps
commands. This should be
sufficient to demonstrate that your system calls work,
alternatively you can create your own test code.
As always you should be able to explain both the design and your implementation.