|
SRG:
NetOS: Student Projects |
Old projects on PegasusBelow is a list of some of the projects related to Nemesis that have been advertised in the past. Note that most of them are no longer suitable for a Part II project; you should probably refer to the current student projects page if you're looking for something to do. This page exists so you can see what's been done in the past.
Some projects that have already been completed remain suitable for further work. These are listed on the other page.
Nemesis runs on Intel PCI based machines. It would be nice for us to be able to provide demonstrations by taking an Intel based portable to the demonstration. This would involve writing code to manage the PCMCIA bus, the LCD controllers, PCMCIA ethernet cards and doing any other changes needed to keep it running on a portable instead. Some of this code could be taken from Linux.
Possible supervisors:
Paul Barham,
Stephen Early.
One student made some progress on this in 1995-96, but since then Nemesis has moved on substantially with many new features and a complete redesign of the way the build process works. It now runs on Alpha (Digital EB164) and Intel (Pentium PCI) machines.
A second student brought Nemesis further up to date during 1996-97, so there is not much mileage left in this project now.
A possibility might be to enhance the current work to a more advanced level, including support for the MMU. You should be happy with ARM assembler and Unix binary utilities such as 'ld' and 'as'. The project could include writing device drivers for ATM networking cards and video etc.
You will learn a lot about low level systems by doing this project but it should be within the grasp of most students.
Possible supervisors:
Austin Donnelly.
This project is only tentative, but we hope to obtain shortly some StrongARM development boards. Otherwise see the RiscPC project above.
Since the project was announced, the boards have been obtained and Nemesis has been ported to them.
Possible supervisors:
Austin Donnelly.
This project would involve possibly writing a suitable device driver for floppy or hard disk drive, and then implementing an MS-DOS filing system to be made available to client domains as part of the Nemesis name space. Posibilities for Fun with the Nemesis model of performance guarantees - e.g. mainting disk bandwidth allocations and so on.
Nemesis now has some disk drivers. I believe that it is no longer sufficiently interesting to be attempted as a project.
Possible supervisors:
Ian Pratt,
Dickon Reed.
The GNU debugger GDB has support for remote debugging, over an RS232 line or TCP connection. We already have support in Nemesis for post-mortem debugging of the entire system follwoing a crash using this system. This project would extend the debugging support to allow interactive debugging of user processes on Nemesis. Lots of fun to be had with breakpoints in a concurrent environment.
This project was attempted in 1996-97. It has now become irrelevant because of the new memory management system, which includes support for debugging individual domains.
Possible supervisors:
Steve Hand,
Stephen Early,
Austin Donnelly,
Code for Nemesis is currently written using highly stylised C, augmented with numerous preprocessor macros. This is because raw C provides support for neither the object-based linkage of Nemesis modules, nor the hybrid type system of the MIDDL interface definition language. As a result Nemesis C code contains much standard boilerplate.
CLUless is a tentative design for a C-like language which maps rather better on to the Nemesis computation model than C. A compiler for CLUless would consist of a parser, type-checker and back-end which would generate C code similar to that currently written by hand.
This has already been done in 1995-96, and 1996-97. Both projects were a success, and the remaining work on CLUless is not enough for a Part II project.
Possible
supervisors: Dickon
Reed.
Nemesis currently has no support for the POSIX standard operating systems interface. Providing one is a challenge, largely due to the use in Nemesis of a single address space shared by all processes. However, with the exception of the fork() primitive and some non-reentrant functions, a POSIX interface can be implemented over Nemesis in a number of ways.
A possible project would look into the various options for providing POSIX-compliancy, and would hopefully result in the ability to compile most POSIX applications "out of the box" for Nemesis.
A POSIX interface is a Pegasus Project deliverable due from Glasgow University (one of Cambridge's partners), and is expected to be completed by the time student projects are due in.
Possible
supervisors: Stephen
Early