|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Kernel APIsThe L4 kernel API has evolved in numerous ways during the lifetime of L4, starting from the initial IA-32 assembly kernels in the early 1990's to the current architecture independent API as implemented in L4Ka::Pistachio. The reasons for changing the API have been many, including the need to support other hardware archietctures and new architectural features, the need for better and more efficient abstractions, and the need to try out new experimental features.Some kernel APIs have, due to their experimental nature, been subject to rapid changes. These APIs are prefixed with an X in their version numbers. The other more stable kernel APIs are numbered without the X in their version number. There currently are four kernel APIs in more or less widespread use: Version 2, Version X.0, Version X.2 (a.k.a. Version 4) and NICTA N kernels. Version 2This is the original L4 API as implemented in Liedtke's assembly kernels. The API supports 64 bit thread IDs with subfields containing (among other things) the thread number, task number, chief number, and version number.The chief field of the thread ID is used for implementing the Clans & Chiefs security model. A thread within a Clan can only communicate with other threads within the Clan or the Chief of the Clan. Any attempt to communicate with any outside parties are automatically redirected to the Chief. The Chief is then used to enforce the communication security policies for the threads within its Clan. Having large thread IDs also enables a relatively large number of threads/tasks to be created. However, the fixed amount of bits allocated to thread numbers and task numbers still makes the scheme unsuitable for many purposes. (There can only be a fixed amount of threads within a task. For most purposes this amount is way too high. For other purposes the amount of threads within a task is too low.) The fixed association of threads to tasks also makes it impossible to migrate a thread to another address spaces---an important operation for, e.g., NUMA systems. The original Version 2 API is very IA-32 specific. APIs for other architectures (e.g., MIPS and Alpha) have been ported to the Version 2 API in ad hoc ways. Version X.0This API was targeted at dealing with some of the problems experienced with the Version 2 API. The API is very similar to Version 2, the most notable differences being the 32 bit thread IDs and the lack of Clans & Chiefs.The change in the thread ID came about because the Version 2 thread IDs were found to be unwieldly and inflexible. Reducing the ID to 32 bits freed up one register for other purposes and made thread ID handling more efficient. The freed up register enabled the IPC ABI on IA-32 to use 50% more registers (i.e., 3 instead of 2) for register only IPC transfer. This boosted performance for many common micro kernel applications. The Clans and Chiefs model of Version 2 was found to be way too inefficient for most purposes (due to the overhead of redirection). The scheme is also unflexible since a thread is tied to a Chief for the complete lifetime of the thread (the Chief is specified in the thread ID). This prevents dynamically changing security policies to be implemented efficiently. With Version X.0 we experimented with other ways to deal with security policies. Most notable is a more flexible and efficient IPC redirection scheme (implemented in IBM internal versions of L4, not in L4Ka::Hazelnut). It should be noted that the Version X.0 API was not meant to necessarily solve all the problems with the Version 2 API. Rather, the API was meant as an experimental, albeit very stable, test-bench to try out new ideas. It was merely meant as a step in the direction of what we envisioned the new improved next generation microkernel API to look like. In particular, the API does not solve all the issues related to flexible and efficient security policy management. Version X.2 (a.k.a. Version 4)This API aims at solving many of the problems we identified while working with the X.0 API. The task IDs are now completely separated from the thread IDs; task (address space) and thread management is separated. The memory management is more flexible. The IPC operation is more powerful and allows for medium and short size messages to be transferred more efficiently. There is support for multiprocessing, and the API enables better control over processor and system resources.Another notable difference for the users of the new API is that there is now a clear separation between API and ABI. This makes Version X.2 compliant L4 applications much more portable. The X.2 API will eventually stabilize and become Version 4. NICTA N seriesNational ICT Australia (NICTA) has created a derivative of the Version X.2 API, targeting embedded systems. The N1, N2 and subsequent APIs aim to improve L4's usefulness in embedded systems by adding features such as asynchronous notification and reducing memory management overheads. NICTA::Pistachio-embedded is the current implementation and is presently supported on the ARM, x86 and MIPS architectures. The ARM implementation is highly tuned and very mature, and deployed industrially.OKL4 seriesBased on the success of the success of the NICTA N series, NICTA has created Open Kernel Labs (OK), a spinout company to support and continue commercial development based on L4. The OKL4 series of kernels continues from the NICTA kernels and OK is working with NICTA to provide a secure, formally verified of L4.Kernel ImplementationsSeveral implementations of the various L4 kernel APIs exist. The following table list all known implementations, their supported APIs and architectures, and their place of origin.
Table footnotes:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Powered by L4Ka | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||