ERTOS Honours Thesis Projects

Introduction

The thesis topics listed here are available to strong undergraduate students. They are mostly associated with research projects and generally quite challenging; many topics have the potential to lead to a publication, and in average we get about one paper a year from the work of one (or more) undergraduate thesis students.

Students who are not aiming for excellence are in the wrong place here. We are generally looking for honours candidates, or students with outstanding performance in operating systems. Specifically we guarantee a thesis topic to any student who has obtained a HD grade in UNSW's Operating Systems or Advanced Operating Systems course, no matter what their other grades are!

Note that the below list is constantly updated, new topics are added as we identify them as work on various research projects proceeds. Topics marked NEW are recent additions.

UNSW students can access all of our recent student theses.

Present topics supervised by Gernot Heiser (official list)

2868: Operating-system kernel for security architecture
The UNSW-NICTA OS group is collaborating with the computer architecture group of Ruby Lee at Princeton University on a highly-secure computer system. It uses a combination of hardware and software mechanisms to build a chain of trust that enables the execution of software in a guaranteed trustworthy environment. The seL4 kernel will be the starting point for the lowest OS layer for this architecture. This project is to design a (formally verifiable) kernel, based on seL4, and develop a prototype (using a simulator for the hardware).
This topic is suitable for a research thesis.
2867: L4 vs Singularity
The open-sourcing of the Singularity opeating system makes it possible to perform an in-depth comparison with L4. Such a comparison is of significant interest (and publishable) as Singularity and L4 are the leading examples of the two alternative approaches to protection: using language (Singularity) or hardware (L4) mechanisms. The thesis is to perform such a quantitative comparison. This includes comparing performance (IPC, thread- and process creation/deletion, lmbench, macrobenchmarks) as well as security-related measures (eg size and nature of the trusted computing base).
1445 (GH146): X server for OKL4
In recent years the X windowing system, originally designed for desktops, has become more prevalent on embedded system. This is mostly driven by the widespread use of X, provision of an X server therefore significantly increases the amount of software that can be easily ported to an embedded platoform.
The OKL4 microkernel operating system is becoming widely used in medium- to high-end embedded systems, including mobile phones and other consumer electronics, network infrastructure devices and others. While it can host a virtualized Linux system, a lightweight X server that does not depend on an underlying Linux kernel would be an attractive service for devices that do not have megabytes of memory.
The aim of this thesis is to port an appropriate X server to OKL4. This would involve rewriting the underlying communication mechanism to use OKL4 primitives, rather than socket-based communication. The resulting system is to be evaluated against native Linux.
Needs excellent C programming skills, strong OS background, ability to cope with large and complex software systems. Prior experience with L4 (eg through COMP9242) is highly desired. Industrial thesis at Open Kernel Labs.
1444 (GH145): Linux multiprocessor scalability
Linux is claimed to be scalable to 1000s of CPU. However, experience shows that this is only really true for HPC workloads that do essentially no system calls.
This thesis is to analyse Linux scalability, identify bottlenecks and suggest approaches to resolve them. Specifically develop and run benchmarks that perform concurrent system calls on multiple processors, and measure they overhead as a function of the number of processors. Use profiling to determine the bottlenecks.
This work is in collaboration with HP and is expected to lead to publishable results.
Day-to-day supervision by Peter Chubb.
1443 (GH144): Disk scheduling with latency guarantees
Modern disk controllers re-order disk requests in order to maximise throughput. This means that on a highly loaded disk, individual requests can experience significant latency, as much as 3 seconds. This is unacceptable for many web servers.
This thesis is to evaluate existing approaches to disk scheduling with QoS guarantees, and determine which form the best starting point for a web server scenario. Design a suitable approach, and implement it in Linux. The aim is to get a highly probably (say 99%) worst-case response time of the order of 100ms.
This research is a collaboration with Google and has the potential to lead to a publication. Day-to-day supervision by members of the Gelato team.
1437 (GH143): Dtrace on OKL4
DTrace is a dynamic instrumentation facility originally developed for Solaris. It that allows users to augment operating-system execution with user-defined code. This thesis is to design and implement a Dtrace facility for the OKL4 microkernel.
When dormant, DTrace probes should present no performance overhead. When active, they allow the user to analyse performance profiles, call paths, and identify potential bottlenecks in the OKL4 kernel. Given the extremely short duration of most OKL4 system calls, meeting the no-overhead is a challenge.
The goal is to provide support for the following DTrace providers (or equivalent) in OKL4: lockstat, fbt, sdt, syscall, vminfo, and sched. Performance and usability of the implementation is to be evaluated. Ultimately you want to demonstrate whether such a facility makes sense for a microkernel.
Industrial thesis at Open Kernel Labs.
1436 (GH142): Analysing the L4 IPC fast path
The high-performance OKL4 microkernel uses an assembler “fastpath” to overcome the performance problems resulting from C code in the critical IPC system call path. Relying on assembler code has a high engineering and maintenance cost, and makes formal verification harder. Eliminating the need for assembler code, or, at least, reducing the amount needed, would have significant practical benefits.
This thesis is to analyse the IPC path in order to understand why C compilers do not do a better job on it. It will analyse possible (semantically-invariant) modifications of the C code, in order to investigate how far C performance can be pushed, and whether it can be made competitive with the assembler implementation. This study is to be done on at least two architectures (x86 and ARM) and using several compilers (gcc, Intel compiler, RVCT, maybe Green Hills).
A thorough and insightful evaluation should be publishable in an OS workshop.
1435 (GH141): An Empirical Study of Bugs in the Linux Kernel
Building new, more reliable, operating systems requires good understanding of the sources of failures in current systems. To date, very little systematic knowledge has been collected about types and causes of bugs in operating systems. This project will give answers to the following questions: What types of bugs are most common in system code? How and why are particular types of bugs introduced? What is the typical lifecycle of a bug?
Initially, the study will be confined to a single part of the Linux kernel -- the USB device framework. The project will involve in-depth study and reverse engineering of Linux kernel code. In addition, development of software tools for automatic code analysis may be required.
Results of the project will be incorporated in a research paper that will be submitted to one of the major conferences on operating systems or software reliability.
Day-to-day supervision by Leonid Ryzhyk.
1266 (GH140): Steering-wheel integrated driver controls and display for the Sunswift 4 solar race car
Recent changes to the international technical regulations for solar racing were required to slow the cars below the road speed limit. One new regulation requires a steering wheel. By integrating the driver controls and display into a steering wheel, all driver interfaces with the car can be consolidated in a similar way to Formula 1 racing cars. In addition, the greater visibility and area for controls allows for more functionality to be built into the steering wheel, including all driver controls, data logging, speed control, and a graphical display.
This project will involve the specification, design, manufacture, integration and testing of steering-wheel based computer for a next-generation solar racing car. This will require close collaboration with the UNSW solar racing team. An ideal student would have, or have the ability to very quickly learn, PCB design and low-level software skills.
Day-to-day supervision by David Snowdon
1265 (GH139): Accurate data acquisition for the Sunswift 4 solar race car
The Sunswift solar car has the most advanced electrical system of any solar racing car in the world, with fully-custom electronics feeding real-time telemetry information to the support crew during the race. The car has a 30kg Lithium Polymer battery pack running at up to 164V. Estimating the charge left in the batteries is crucial to implementing good strategy during the race (i.e. never over-filling, or running the batteries flat except at the start and end of the race respectively).
This project would focus on implementing a battery-state-of-charge estimation system for Sunswift electrical systehttp://www.sunswift.com/m. The system would connect to the car's control area network (CAN), allowing these measurements to be read by the driver and wirelessly by the support crew. While the exact approach would be dependent on the student, one method requires an integration of the current into and out of the battery, along with some linear modelling. Ideally, other factors, such as the voltage, would be determined to provide multiple methods of characterisation. Depending on the aptitude of the student, a large number of other useful sensors could and should be developed, including tyre pressure, temperatures, tilt, acceleration, etc. all connected to the car's telemetry network, feeding information to the driver and support crew.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
1264 (GH138): On-race strategy and data analysis software for the Sunswift 4 solar race car
Modern solar racing cars have a limited battery storage (equivalent to about a third of a day's energy needs, running at 100km/h). This charge must be managed over the course of a race in order to complete the race most efficiently (similarly to the way a a Formula 1 team must manage the car's fuel through the duration of a race). Additionally, real-time telemetry data from the car must be analysed to determine the car's correct operation, and the severity of any faults. Data about the course, data being transmitted from the car itself, data from sensors around the support fleet (wind speed/ direction, solar radiation, road conditions, etc), and anecdotal data from the support crew can all be taken into account.
This project would first of all develop models for the behaviour of a solar car. A testing scheme would be developed and data gathered (via on-road testing) to characterise the models. A software system would be developed to analyse data coming from the car with respect to these models. Finally, methods for choosing the speed at each point along a pre-surveyed course would be implemented. The entire package should be tested on-road with Sunswift 3 in preparation for future solar car races. Depending on the success of the strategy decisions, the optimal speed could be fed back to the car's cruise control system in real-time, allowing for intelligent, efficient, autonomous cruise control.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
1263 (GH137): Maximum power point tracking for the Sunswift 4 solar race car
Maximum power point trackers allow a solar panel to operate under its optimal operating conditions. They are a power electronics device which converts between the panel's optimal operating voltage and the output voltage which is determined by the battery state of charge. MPPTs have generally been a weak point of the Sunswift race cars. The team have designed a highly efficient (>98%) MPPT, with reliable hardware, but the control software has a number of issues which causes the devices to behave sub-optimally.
This project would, depending on the student's aptitude, first of all perfect the control software for the MPPTs in Sunswift 3. Secondly, implement new features such as diagnostics (IV curve sweeps) and improved tracking algorithms (aiming to improve the solar array power output), and explore efficiency-increasing behaviours (e.g. synchronous rectification). Lastly, depending on the available time, the student would look at implementing improved MPPT hardware based on a novel power-electronics architecture.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
1221 (GH135): Forensic-friendly operating system
Computer forensics deals with extracting information from computers after crimes (be it that the computers were used as a tool by a criminal, or that the computer itself is the crime scene). It also is about the design of computer systems to support forensic analysis. This thesis investigates microkernel-based system designs in this context. For example, given formally verified microkernel (that has been shown to be secure against attempts to compromise it), how can this be leveraged into constructing a system where it is impossible to destroy evidence of break-ins.
The thesis will survey the relevant literature of computer forensics, propose a design of a forensic-friendly microkernel-based system, and implement a prototype.
1180 (GH134): Darbat Resource Management
When virtualising an operating system, getting it working is only half the story. Darbat is a para-virtualised version of Darwin, the kernel of Apple's Mac OS X operating system. Darbat runs on the L4 microkernel. Several Darwin instances can run concurrently on the same L4 kernel.
This thesis will involve examining resource management issues in Darbat. It will require examining static policies such as partitioning as well as dynamic techniques for scheduling and VM management. An analysis of the trade-offs involved between performance and security will be required. Optionally, this project may involve building a user interface for runtime management of resources.
1179 (GH133): Darbat Aqua
Darbat is a version of Darwin, the kernel of Apple's Mac OS X operating system, on the L4 microkernel. Currently Darbat supports a single-user shell prompt as well as user input device drivers, however it can not run the full OS X GUI.
This project involves putting in the necessary features to the Darbat virtualisation layer to support running OS X GUI applications. This will require working at the L4 level as well as Darwin kernel hacking.
1178 (GH132): Crashable I/O Kit Drivers
Darbat is a version of Darwin, the kernel of Apple's Mac OS X operating system, on the L4 microkernel. I/O Kit is the device driver framework for OS X, including the actual drivers. Darbat presently runs all I/O Kit device drivers in a single user-mode process on L4.
This thesis aims to run multiple I/O kit processes on a single machine, in order to confine device drivers. Part of this thesis will involve measurement of different system architectures to evaluate the trade-offs in user-level I/O kit device drivers. The major goal is to allow a system to continue with minimal disruption when a non-essential device driver crashes.
1038 (GH129): Afterburning Linux on Itanium
Afterburning, also called pre-virtualisation, is a way to semi-automatically virtualise an operating system to run in a virtual machine. Unlike the better-known para-virtualisation technique, the result is an OS binary that can run on any hypervisor as well as on bare hardware. Yet, pre-virtualisation achieves the same performance as para-virtualisation.
Pre-virtualisation has been fully implemented on x86 hardware in a collaborative project between NICTA, UNSW and the University of Karlsruhe. On Itanium, the NICTA/UNSW so far has produced a partial implementation, that does not yet produce a binary that can run on hardware as well as any hypervisor. There are a number of reasons why the x86 approach doesn't easily translate to Itanium.
This thesis is to design, implement, benchmark and optimise full pre-virtualisation on Itanium, for bare hardware and the Xen and vNUMA hypervisors. If time allows, the L4 microkernel and Linux can also be supported as hypervisors.
Day-to-day supervision by Peter Chubb or Matt Chapman
835 (GH125): Fault-tolerant embedded system
Microkernels provide hardware-enforced encapsuation of system components. This provides fault containment and a basis for fault tolerance.
This thesis is to inviestigate approaches to component-level fault tolerance applicable to the L4/Iguana embedded operating system and the CAmkES component architecture. It is then to design, implement, test and benchmark a fault-tolerant prototype demonstrating the viability of one or more of those approaches.
834 (GH124): Elan compiler for L4/Iguana
Elan is an elegant and high-level language which was extensively used in L3, the predecessor of L4. Source for an Elan compiler for L3 (written in Elan) is available. Availability of an Elan compiler is a pre-requisite for migrating existing commercial L3 installation to the L4/Iguana operating system.
This project is to port the Elan compiler to Linux and re-target it for L4/Iguana. As the compiler itself is written in Elan, this will require bootstrapping it on the new environment.
741 (GH122): T-Kernel on L4
μITRON is an API specification for a real-time OS kernel that is widely used in the Japanese and Korean industry. The basic μITRON specification is aimed at MMU-less micro-controllers. An implementation of this ``unprotected'' μITRON on L4 has recently been done by a local student.
In practical terms, however, running L4 on hardware without memory protection is pointless, and hence an implementation of unprotected μITRON on L4 is of limited practical use. There is a ``protected'' version of the μITRON API (for microprocessors with memory protection), but it is presently available in Japanese only. Moreover, it seems that it has found little uptake in industry. Instead, a new standard has emerged in the TRON family: the T-Engine, which is a standardised embedded platform, with a standard OS, the T-Kernel.
This project will analyse the T-Kernel specification, understand how it can be mapped to L4, and design and implement an L4-based T-Kernel prototype. This may be based on the existing μITRON implementation.
724 (GH118): Sunswift components
A number of Sunswift issues that can be tackled by a thesis student include:
- Improved CAN nodes (less power consumption, more isolation, utilise improved controllers to improve connection reliability)
- Design and build tyre-pressure sensors
- Reliable wireless communication with support vehicle
The actual thesis topic would be decided depending on the skills and interests of the student.
Day-to-day supervision by David Snowdon
721 (GH115): Optimiser for Itanium System Code
Low-level Itanium system code, such as TLB miss handlers, often needs to be written in assembly code. Instruction scheduling is explicit in Itanium assembly code, so good scheduling is time-consuming, makes the code difficult to read, and requires a separate implementation for each processor model. We suggest a better solution would be to write the assembly code in "unbundled" form, and implement an optimisation tool which uses some appropriate constraints and heuristics to decide how to order and bundle instructions.
Day-to-day supervision by Matthew Chapman
605 (GH110): Multi-kernel fault tolerance
Fault tolerance of computer systems is important in mission-critical applications. A number of standard approaches to fault tolerance exist, including hardware- and software redundancy. However, protection from redundancy-based approaches is limited, as long as the redundant components are identical, and thus likely to fail in exactly the same way at the same time. A more reliable approach to redundancy-based fault tolerance would employ components that are independently engineered to the same (or compatible) specification.
While this is a reasonable approach at the application software level, the cost of independently manufactured operating systems is normally prohibitive. Given that failure of the operating system is generally fatal for the system, this implies serious limitations for practical fault tolerance.
However, the small size and simplicity of a microkernel could make kernel-level redundancy feasible. Furthermore, on some architectures there already exist independently engineered implementations of the L4 microkernel, namely L4Ka::Pistachio and Fiasco. This thesis is to investigate the use of these independent kernels as a redundant fault-tolerant operating systems platform on a suitable SMP or SMT system, and design and implement a prototype.
If successful, this work can lead to a landmark publication.
594 (GH109): BLUEsat OS
Design and implement an operating system for the BLUEsat student satellite project. The operating system will require a high degree of fault tolerance, including resilience against memory errors, and a very high degree of robustness.
498 (GH99): Multics on modern hardware
Forward-port Multics to Itanium or 64-bit PowerPC.
While this topic had originally been posed as a joke (which not everybody got), the recent release of Multics sources means that this could be looked at seriously. Nevertheless, it isn't for the faint-hearted!
488 (GH96): Sunswift OS
Design and implement an L4-based operating system for Sunswift, the UNSW solar racing car. Sunswift features a CAN-based control system with a PLEB for central coordination and external communication. The PLEB presently runs Linux and L4.
This project will build a new, lightweight OS for Sunswift, specially designed to meet the car's requirements for real-time control, communication and reliability. It will be based on Iguana and serve as a demonstrator for the groups embedded-systems framework. Suitable for a student with a good OS background, L4 experience and an interest in embedded systems and interfacing to hardware.
486 (GH94): JVM on L4
Port a Java virtual machine (JVM) to L4. This will provide a minimal Java environment for L4-based embedded applications and constitutes an important step into making L4 an ideal base for building embedded systems.
293 (GH85): L3 on L4
L3 is a persistent operating system which has been in commercial use for 20 years. It is also in a sense the predecessor of L4. However, L4 is a very minimal kernel, which requires general system services, such as those provided by L3 (or UNIX) to be provided by user-level servers.
The existing user base of L3 presents a potential user-base for an L4-based system, provided a (more-or-less) L3-compatible system could be provided on top of L4. The purpose of this thesis is to examine the structure of L3, design an L3 emulation on L4, and implement a first prototype. Schönbeck, the present L3 maintainers, have agreed to help.
57 (GH46): Port L4Ka::Pistachio to SuperHitachi or MC68000
Port Pistachio, the latest L4Ka kernel, to the SuperHitachi or Motorola 68000 architecture. This will cover the last outstanding mainstream general-purpose architectures and make L4Ka a truly platform-independent kernel. It will also open the way for deploying L4 in the Japanese and the embedded industry.
Serious operating system kernel hacking.... Only suitable for students with very strong OS background and a good understanding of architectural issues.

I will not take on students who have not shown a convincing performance in COMP3231 ``Operating Systems''. I normally expect students to have done COMP9242 ``Advanced Operating Systems'', although I make exceptions in special cases.

Most topics can lead to publications.

Present topics supervised by Ihor Kuz (official list)

Background

The following projects are related to embedded systems applications and componentised embedded operating systems. We are looking at a wide range of embedded applications in order to get a feel for the complexity and issues involved in designing and building such systems. We will use this experience to aid in the further design and development of an embedded systems framework (a software framework for building and deploying embedded applications) and embedded component architecture (a component-based programming architecture especially targeted at embedded systems).

Topics

IK24: Non-C languages on L4
Currently almost all software for L4-based systems is written in C. There are however many languages whose runtimes or interpreters could be ported to run on L4 as well. For example, Python was ported to Mungi, an early version of Io was made to run on L4, as was a very simple version of the Squeak Smalltalk system, and Lua was also ported to L4/Iguana. However, none of these run on current versions and, as such, we are still limited to using C for programming all L4-based applications. In this project you will choose a favourite language and port its runtime or interpreter and critical libraries to run on L4. Furthermore you should integrate the language into the L4 environment such that code written in that language can invoke L4 system calls, perform IPC and transfer data to processes implemented in other languages. (see also GH94: JVM on L4)
IK23: Shared resources in an microkernel-based OS
One of the key services that an OS provides is a managing access to shared resources. For example, a file system manages access to shared disk space, a network stack manages access to a network device, a window system manages access to the display, etc. In a modular, microkernel-based OS, these shared resources are managed by user-level services. In this project you will investigate ways of modelling such shared resource managers within the CAmkES component framework on L4 and develop a suitable model for building such services in a componentised environment. You will assess the suitability of this model by designing, implementing, and evaluating one or more such services (e.g., a file system, a network stack, etc.).
IK22: Component Architecture on Secure Microkernel
The seL4 kernel is a new secure version of the L4 microkernel. CAmkES is a component architecture designed for building microkernel-based operating systems. Currently CAmkES is based on L4 and does not address security issues. The aim of this project would be to get CAmkES working with seL4 and then explore the ways that seL4 security features can be leveraged by CAmkES to build secure embedded systems.
IK15: Video game console
Design a video game console system (based on CAmkES and L4) that is programmable but cannot be 'hacked' i.e., games cannot be used to override the default OS or other security software.
IK14: Programmable security camera
Design and build a networked and programmable security camera based on L4/Iguana. It is basically a regular security camera that can be programmed to do image manipulation, analysis, etc. directly in the camera. There are numerous security issues involved, e.g., there must be a tamper proof way of marking images as originals. There are also real-time issues to deal with.
IK11: Display architecture for L4
Explore the possibilities for a display (GUI) architecture for L4/Iguana. It should be flexible so that it can be used on many different kinds of (embedded) displays (PDAs, phones, watches, media players, etc.). The project will include exploring existing embedded graphics display architectures (e.g., QT/embedded) and evaluating whether basing such an architecture on L4/Iguana would provide benefits or drawbacks.
IK10: Click Modular Router on L4
Investigate, design and implement a Click compatible modular network router architecture on L4 making use of the CAmkES component framework. Click is a software architecture for building network router software from small, reusable, software components, while CAmkES is a component-based framework for developing L4-based systems. Given the componentised nature of both Click and CAmkES, it should be possible to define a Click router in terms of CAmkES components. The project will require you to design a framework on L4 that will allow Click components to be reused to build network routers. Besides designing and implementing this framework, you will also reuse existing Click components to build several variations of network routers and compare the performance of your implementation to existing Click implementations.

Present topics supervised by Stefan M. Petters (official list)

Projects

SMP01: C++ source code analysis for real-time systems
An essential step in the estimation of the worst case execution times of software, is the establishment of a control-flow-graph of the software. This can be either achieved by analysing the source or the object code or the traces provided by a program execution. However, neither analysis alone yields the correct picture. This source code provides only a rough picture, due to the results of optimisations performed by the compiler, while many issues like, for example, indirect branches and calls, can not be resolved by looking at the object-code alone. The analysis of traces is unsafe as only observed transitions between basic blocks will be considered. In order to apply a worst case execution time analysis on L4 micro kernel code, a parser of a subset of C++ code is essential. This should establish the control flow graph of the source code and yield additional information, which is otherwise hard to establish from the object code, like loops with multiple exit or continue conditions, bounds on the number of loop iterations were possible, possible jumps/calls to multiple destinations in the code. This step will also be used to automatically introduce instrumentation into the source code.
SMP03: Fusion of Several Control Flow Graphs
Structural analysis of code is one of the major steps for the real-time analysis of code. There are several approaches to this problem, but none of these is ultimately right. The structural analysis of source code, for example, suffers from optimisations done by the compiler, which might change significantly the structure of the code. Object code analysis, in turn, has considerable problems of identifying indirect function calls. Within this project a mechanism to fuse the information available in several control flow graphs available in an XML file has to be designed and implemented. This requires some pattern matching and rules how to integrate conflicting information.
SMP04: Coordination Instance for a Detailed Execution-Time Analysis
One aspect of the estimation of the longest execution time of real-time software is the influence of the implementation of a given algorithm. Often small changes in the implementation can result in major changes in the overestimation. This project is focussed on identifying possible sources of overestimation and inform the user, where in his code, hand optimisation looks most promising. Typical examples are code, which is only executed in the first iteration of a loop and thus lead to severe overestimations, or small if-then-else constructs, which may be recoded to allow for larger units to be analysed. Supervision will be directly by a Senior Researcher.
SMP05: A Real-Time Programmers Guide Dog towards Better Predictable Software
One aspect of the estimation of the longest execution time of real-time software is the influence of the implementation of a given algorithm. Often small changes in the implementation can result in major changes in the overestimation. This project is focussed on identifying possible sources of overestimation and inform the user, where in his code, hand optimisation looks most promising. Typical examples are code, which is only executed in the first iteration of a loop and thus lead to severe overestimations, or small if-then-else constructs, which may be recoded to allow for larger units to be analysed. Supervision will be directly by a Senior Researcher.
SMP06: GUI Implementation for an Analysis Tool
The worst-case execution-time analysis of code is performed by many different steps. Furthermore there are a number of different views the person analysing a piece of code may have. This GUI would need to coordinate the analysis steps and provide a suitable extensible user interface to access all available informationen in an efficient way and allow the user to interact with the analysis. The project will be in close collaboration with a senior researcher.

How to apply:

Contact the relevant supervisor.

Note: We promise a thesis topic to every interested student who has obtained a HD grade in COMP3231/COMP9201 Operating Systems or COMP9242 Advanced Operating Systems. If necessary we will define additional topics to match demand.

We will not turn down any students doing exceptionally well in OS courses. However, this does not mean that an HD in OS or Advanced OS is a prerequisite for doing a thesis with me. Interested students with lower OS marks are welcome to talk to me if they feel they can convince me that they will be able to perform well in an OS thesis.

Keep in mind that these topics are all research issues and generally at the level of Honours Theses. They are not suitable for marginal students or students with a weak understanding of operating systems. We expect you to know your OS before you start.

Past thesis reports and DiSy thesis rules (internal access only)

Postgraduate thesis topics:

Undergraduate thesis topics are also suitable for coursework Master's projects. Same conditions apply: You must have a pretty good track record in OS courses.

Information about research theses

Return Home

ERTOS Honours Thesis Projects

Introduction

Undergraduate Thesis Topics

Present topics supervised by Gernot Heiser (official list)

Present topics supervised by Ihor Kuz (official list)

Background

Topics

Present topics supervised by Stefan M. Petters (official list)

Projects

Related topics supervised by Gerwin Klein (official list)

Projects

Related topics supervised by Kevin Elphinstone (official list)

Projects

How to apply:

Postgraduate thesis topics: