Fiasco vs Hazelnut
esk at ira.uka.de
Fri Mar 14 13:23:14 CET 2003
[Jacob Gorm Hansen]
> On Fri, 2003-03-14 at 01:58, Cristiano Ligieri Pereira wrote:
>> I certainly looked through the FAQs first before posting this
>> question but did not find any clean distinction between both kernel
>> versions. I was already told and could check myself that there are
>> performance differences. Are these differences described anywhere
>> in the website and I missed it?
>> What are the major differences between these two?
> From a user perspective I think these are the main points:
> - Fiasco supports 64 bit thread ids, aka 2047 rather than 255
> maximum tasks.
> - Fiasco implements a little more security, especially in relation
> to task ownership.
> - Fiasco's debugger has more features.
> - Hazelnut has faster IPC.
> From my own experience I would say that if you wish to program
> something for L4, use Fiasco, and if you want to run benchmarks, use
Several people seem to be confused about what the different kernel
versions actually implement and what the reasoning between the various
kernel versions are. I think the whole issue warrants some
There are currently three L4 APIs in more or less widespread use:
Version 2, Version X.0, and Version X.2 (aka, Version 4):
Version 2 -- This is the original L4 API as implemented in Jochens
assembly kernels. The API supports 64 bit thread IDs with
subfields containing (among other things) the thread no, task no,
chief no, and version no.
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 to high. For other purposes the amount of threads within
a task is to low.) The fixed association of threads to tasks
also makes it impossible to migrate a thread to another address
spaces---an important operation for NUMA systems.
The original Version 2 API is very ia32 specific. APIs for other
architectures (e.g., MIPS and Alpha) have been ported to the
Version 2 API in ad hoc ways.
Fiasco implements the Version 2 API.
Version X.0 -- This 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 to be 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 to
inefficient for most purposes (the overhead of redirection was
too great). 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 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 (hance the X in the version number) 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.
Hazelnut implements the Version X.0 API.
Version X.2 (aka. 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.
The most 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 (Version 4) compliant L4 applications much more
Pistachio implements the Version X.2 API. Current architectures
supported by Pistachio are: ia32, ia64, PowerPC, MIPS, and Alpha.
The Version X.2 API is meant to eventually stabilize and become
Hope this shortish summary helps.
More information about the l4-hackers