address@hidden: Re: Fiasco vs Hazelnut]

[Farid Hajji]

Hi,

to all of you not subscribed to l4-hackers@,
the following mail from Espen clarifies the
differences between the various L4 kernels
out there.

Sorry for the spamming if you've already
read this.

-Farid.

------- Start of forwarded message -------
X-From_: address@hidden  Fri Mar 14 13:25:13 2003
From: Espen Skoglund <address@hidden>
To: Jacob Gorm Hansen <address@hidden>
Cc: Cristiano Ligieri Pereira <address@hidden>,
   l4-hackers <address@hidden>
Subject: Re: Fiasco vs Hazelnut
In-Reply-To: <address@hidden>
Sender: address@hidden
Date: Fri, 14 Mar 2003 13:23:14 +0100
X-Spam-Status: No
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)

[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
> Hazelnut.

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
explanation.

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
     portable.

     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
     Version 4.

Hope this shortish summary helps.

        eSk


_______________________________________________
l4-hackers mailing list
address@hidden
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
------- End of forwarded message -------


-- 
Farid Hajji -- Unix Systems and Network Management.
http://www.farid-hajji.net/address.html
Quoth the Raven, "Nevermore." --Edgar Allan Poe.