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

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

 
Documentation
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
 
History
2007
2006
2005
2004
2003
2002
2000
1999
1998
- 1997
 
Staff
- Gernot Heiser
- Kevin Elphinstone (LiC)
- Guest Lecturers (TBA)
 
Stureps
- Student Reps

 
Valid HTML 4.0!

M4: File System

The SOS file system features a flat directory structure, containing files and the terminal device console. Files have attributes (like size, creation time, permissions) that can be accessed through appropriate systems calls. All I/O primitives provided by SOS are synchronous (blocking).

You will need to maintain file descriptors containing a present read position in the file. This requires some minimal process descriptor block (PCB) data structure. Again, you will need to modify this structure as you go on, so do not waste too much time on the full details right now. You may wish to initially only deal with a single client process, data on which is kept in a single PCB variable. This avoids dealing with process IDs for the time being.

The low-level file system is implemented by the NFS file system on your host machine. You are provided with an NFS client library for accessing files on your host Linux machine. Once again, it is your responsibility to understand the working of the provided code.

IP stack and NFS

In the code you are provided with a sos/network.c file, which provides network_init(). You will need to uncomment the nfs initialisation code in sos/network.c.

Apart from the initialisation and mounting filesystems, the NFS library provides an asynchronous interface, which means when you call the function, you must also provide a callback function which will be called when the transaction is completed. This should make it easy to provide a blocking interface each clients, without blocking the whole system.

The NFS server you will be talking to is your host machine. The filesytem you mount is /var/tftpboot/$USER, you will have to change the line in sos/network.c for your user name.

Design issues

One of the major issues you will need to deal with in this milestone is converting an asynchronous interface (as provided by libnfs) into a synchronous interface (as required by the system call interface).

If you are planning on doing the file system caching, or dynamic file system advanced component you should probably consider them in your design now.

Assessment

You must have some test code to demonstrates that you have implemented the open, close, read, write, getdirent and stat system calls. I would suggest adding a cp command to sosh, this will test both reading and writing a file. A cp , together with the supplied ls command, should be sufficient to show that your implementation works.

As always you should be able to explain any design decisions you made, specifically, the design of your open file table and how you dealt with the asynchronous/synchronous problem.


Last modified: 27 Jul 2007.