IoL4 Architecture


Currently IoOS/L4 is divided up into several components.

      • IoVM – Currently a stock unmodified IoVM taken from the Io programing language page.
      • libCLight – A minimalistic libc implementation. IoVM is linked against this.
      • Sigma0 – This is task that L4 spawns to handle initial memory allocation.
      • L4 – The L4 microkernel itself. In theory any L4 implementation will suffice, as long as it implements the X.2 version of the spec or later. The reference implementation, L4ka::Pistachio is being used for development.

Memory allocation

libCLight contains a copy of Dough Lea’s malloc implementation, and a very simplistic implementation of sbrk and brk. As part of the initialisation process, it will request a static page contigious memory region (~16MBs) from Sigma0 for the heap backing store. This will change and will be modified to be more dynamic, and possibly support for paging will be added.


Currently the input and output routines will use services provided by the L4 kernel debugger in liew of a real console. While this will suffice in early stages of development it will be neccecary to add a real console/frame buffer interface later on.

System call interface

Once the IoVM port is up and running (boots and passes regression testing), a system call interface will be written to allow Io programs to make L4 system calls. As there are only 12 system calls provided by L4, and the availability of a C library “Convinence programing interface”, it should be possible to implement this as a normal Io object.

Hardware access

It is tenatively planed that some sort of hardware abstraction layer be implemented so that it is possible to write device drivers in Io. More needs to be discussed and planned on this once the target platform(s) become more apparent. The one possible issue is that the top half interupt handlers should and most likely will be writen in C due to restrictions on what is possible at various IRQ levels, and the fact that the code is extremely speed sensitive. It might be advantageous to use TU-Dresden’s Omega0 for interupt handling as it should significantly ease portability.


Extensions to the Io coroutine interface will be made to provide the ability to spawn off a new separate IoVM instance, optionally at a lower priviledge level. Current plan is to use the L4 scheduler to implement premtive multitasking between the “kernel” and “user” VMs. It is also currently under consideration if it would be worth implementing Io coroutine support as actual L4 threads, and have them also preemtivelys scheduled. (Limbo from Bell Labs uses a similar mechanism).


It is open to debate if a “real” traditional filesystem should be implmented or if it is sufficient to provide a mechanism for checkpointing IoVM state/objects. Further investigation is needed.


Leave a Reply

Your email address will not be published. Required fields are marked *