[CSE]  Advanced Operating Systems 
 COMP9242 2008/S2 
CRICOS Provider
Number: 00098G

PRINTER Printer-Friendly Version
- Notices
- Course Intro
- Consultations
- Survey Results
- Lectures
- Selected Papers
- Project Spec
- Exam
- Forums
Project Resources
Slug Lab
L4 Debugging Guide
Developing on a Mac
Developing on Linux
SOS source browser

OKL4 reference manual
Elfweaver user manual
IXP42X hardware manual 
OKL Wiki
NSLU2-Linux HomePage
Intel IXP400 Software

Related Info
IBM OS Prize
OS Hall of Fame
- 1997
- Gernot Heiser
- Kevin Elphinstone (LiC)
- Guest Lecturers (TBA)
- Student Reps

Valid HTML 4.0!

M3: System call interface

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 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 calls should output system call not implemented.

Console device

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).

You may once again find the documentation on libserial handy.

Changing your SConstruct

You will need to create a new library and to change your top-level SConstruct 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 libs/sos directory with 2 subdirectories libs/sos/include and libs/sos/src, and place your source file into the src/ directory. You will also need to create a SConscript file to tell make system how to build your new library. Its format should be self-evident from the other libs/*/SConscript files in other provided libraries. Finally to include your new library and build the sosh application, you will need to change your top-level SConstruct file:

from: milestone = 0
  to: milestone = 3

Once you have your libs/sos library set up, it should like like this:


You should copy the contents of tty_test/ttyout.c to libs/sos/src. You can consider this new file as the acorn from which the entire grand tree of -lsos will flourish.

Design alternatives

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:

  • Transfer data in message registers.
  • rootserver maps a user fpage in to itself.
  • Set up a region of memory which is shared between the kernel and each user process and memcpy data into it when you need to transfer data.
  • Use copyin-copyout method, where you lookup the page table and your system copies and data in to/out of physical memory.

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 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.

Last modified: 25 Aug 2008.