Screen Version
School of Computer Science & Engineering
University of New South Wales

 Advanced Operating Systems 
 COMP9242 2004/S2 

AOS Design Guide


The AOS project is a very large and complex system. Often the system is built in an ad-hoc manner with little or no design beforehand, frequently with the attitude that it will be cleaned up later.

This design methodology typically produces a system with only partial functionality. This also involves a lot of writing and re-writing the same code. It is usually also the case that "I'll do it later" never eventuates.

This page lists some of the design choices involved when building SOS to allow you to better understand the difficulties before they occur. You are free borrow or ignore as much or as little of this information as you like. This is only a guide, and any SOS project you want to produce is fine.

Data Structures and Subsystems

While designing SOS you will need to consider a number of different subsystems and data structures, and how they inter-relate.

Some systems you will need to consider include:

Some systems you probably don't need to implement, but still might like to consider are:

Inter-process communication

In Milestone 0 you are required to pass data from an application to the OS in the form of text data for printing. This is an example of passing parameters and data between L4 address spaces.

There are many ways to pass data between applications, not limited to the following:

Which model you use is up to you, however some mechanisms are more appropriate for some systems and not others (eg. copyin/copyout will not work well with a multi-server OS). A poorly designed IPC primitive is a common problem and leads to an inefficient system. You must ensure it is capable of providing fast communication (eg. simple system calls) and also efficient when dealing with large amount of data (eg. file access). You must also ensure your IPC mechanism is free of DOS.

You are free to use existing systems for interface and stub generation, eg. IDL4.


Debugging your SOS project can often be a very difficult task. For more information on debugging in L4 have a look at this page.

L4 Server Thread Management

Regardless of what kind of OS personality you choose to write, you will need to deal with multiple asynchronous requests to your L4 server(s). There are a number of ways this can be achieved. Once again, this list is neither exhaustive nor truly distinct.

All the above techniques are valid for use in SOS. Each has their own advantages that make them easier/nicer/faster/better/whatever. They also have their own problems with implementation and testing. Make sure your solution is deadlock free, DOS free, thread safe, efficient and easy to debug.

Advanced Work

In AOS you are encouraged to do extra work that you are specifically interested in. This can be in the form of additions to the SOS project, or entirely different OS related projects. Some suggested SOS enhancements for extra marks are listed below. Feel free to come up with your own ideas. If you would like to do one of these (or your own suggestion), talk to us about what is to be done and how marks will be awarded.

Disclaimer: None of these advanced features is easy or trivial. You should avoid making your project dependent on any of these as there is a good chance you will not complete it. You should try to make sure you at least one to two milestones ahead of the marking schedule before you attempt one of these. The motto is "make it work, then make it fancy".

Alternate System Models

There are a number of different general system structures you can use when building an OS personality on top of L4. A few major categories are listed here. Be aware that this is in no way an exhaustive list, and you are encouraged to come up with or design your own. These categories are also very rough, and in no way well defined.

Last modified: 09 Aug 2004.