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

PRINTER Printer-Friendly Version
Administration               
- Notices
- Course Intro
- Consultations
- Survey Results
 
Work
- Lectures
- Selected Papers
- Project Spec
- Project FAQ
- Exam
 
Forums
- Forums
- Can't Login?
 
Documentation
- Project Resources
- ASysT Lab
- Using Sulima
- L4 Debugging Guide
- L4Ka::Pistachio FAQ
- L4 source browser
- SOS source browser
- L4 reference manual
- L4 user manual
- Sulima ISA Simulator
R4x00 ISA Summary 
MIPS R4700 ReferenceMIPS R4000 User Manual 
- GT64111

 
Related Info
- Aurema OS Prize
- OS Hall of Fame
 
History
- 2004
- 2003
- 2002
- 2000
- 1999
- 1998
- 1997
 
Staff
- Gernot Heiser (LiC)
- Kevin Elphinstone
- Guest Lecturers (TBA)
 
Stureps
- Student Reps

 
Valid HTML 4.0!

Device library

The device library contains some function which can simplify writing device drivers, and more importantly abstracts operating system specific details so that drivers can be portable between different operating systems. This is most important for the device drivers that we provide for you such as the serial and network drivers.

You may wish to use this library directly when writing your clock driver. Depending on the design of your operating system you may wish to modify libdevice. This library depends on the structure and functions you provide in SOS.

Memory allocation

The function get_pinnable_memory is used by device drivers to allocate memory that can be accessed by the DMA controller. The current implementation uses the frame_alloc function that is implemented in frames.c. If you change the interface to your frame table you should ensure that you also change get_pinnable_memory. This also means that if your frame_alloc doesn't work then you will probably break the device drivers.

Device mappings

The function map_physical is used by device drivers to map the physical address space (where device registers are mapped) into the driver's address space. For you purposes, the first argument, host can be passed as NULL.

Interrupts

The other aspect that impacts on you is the handling of interrupts. When a device driver needs a CPU interrupt it will call register_cpu_interrupt_handler, to which it passes a handle (which in SOS, is just NULL), the irq it wants to receive notifications from, and a pointer to a function which should be called whenever the given interrupt occurs. The mapping from irq to handler function is stored in the irq_handlers array.

The current implementation sets the root thread as the interrupt handler for any registered interrupts. You may wish to change this implementation so that each interrupt is handled by a different thread. The implementation of SOS we have provided to you calls the function irq_handler whenever an interrupt occurs. This function decodes which interrupt occurred, and calls the registered function. If you change this implementation you will need to ensure that the correct function is called when an interrupt occurs.


Last modified: 29 Jul 2004.