RE: enabling/disabling trampoline
This sounds like a problem with RMGR. Try either running L4Linux not using the "flat clan structure" (make xconfig) or enable the "Jochen compatibility/bug mode" for Hazelnut. Have you tried running the binaries of the provided RC2 tarball? They also contain a working L4Linux binary. - Volkmar
-----Original Message----- From: Cristiano Ligieri Pereira [mailto:cpereira@ics.uci.edu] Sent: Thursday, March 13, 2003 9:01 PM To: Espen Skoglund Cc: l4-hackers Subject: Re: enabling/disabling trampoline
I'm not managing to get hazelnut working properly. It boots but then when it creates the Linux panics with the following messages:
Kernel panic: failed to create ping pong task In swapper task = no syncing --- Linux panic ---
Might be something stupid but I can't figure it out. Any suggestion?
Cristiano.
right on! It works with the configuration changes you've suggested. thanks, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira On Thu, 13 Mar 2003, Volkmar Uhlig wrote:
This sounds like a problem with RMGR.
Try either running L4Linux not using the "flat clan structure" (make xconfig) or enable the "Jochen compatibility/bug mode" for Hazelnut. Have you tried running the binaries of the provided RC2 tarball? They also contain a working L4Linux binary.
- Volkmar
-----Original Message----- From: Cristiano Ligieri Pereira [mailto:cpereira@ics.uci.edu] Sent: Thursday, March 13, 2003 9:01 PM To: Espen Skoglund Cc: l4-hackers Subject: Re: enabling/disabling trampoline
I'm not managing to get hazelnut working properly. It boots but then when it creates the Linux panics with the following messages:
Kernel panic: failed to create ping pong task In swapper task = no syncing --- Linux panic ---
Might be something stupid but I can't figure it out. Any suggestion?
Cristiano.
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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? Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira
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.
Jacob
[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
On Friday 14 March 2003 13:23, Espen Skoglund wrote:
Fiasco implements the Version 2 API.
AND version X.0.! Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## E-Mail: fm3@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/~fm3 ##
On 14 Mar 2003 10:26:00 +0100, Jacob Gorm Hansen <jg@ioi.dk> said: JGH> 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:
JGH> - Fiasco supports 64 bit thread ids, aka 2047 rather than 255 maximum JGH> tasks. JGH> - Fiasco implements a little more security, especially in relation to JGH> task ownership. Is "a little more security" similar to "a little bit pregnant"? I don't think either has a real security model implemented. Most of the V2 kernels (x86, Alpha, MIPS) have it, but none of the later ones AFIK. Gernot -- Gernot Heiser School of Computer Sci. & Engin. Professor of Operating Systems The University of NSW Phone: +61 2 9385 5156 UNSW SYDNEY NSW 2052, Australia Fax: +61 2 9385 7348 http://www.cse.unsw.edu.au/~gernot
Gernot,
- Fiasco implements a little more security, especially in relation to task ownership. Is "a little more security" similar to "a little bit pregnant"?
I don't think either has a real security model implemented. Most of the V2 kernels (x86, Alpha, MIPS) have it, but none of the later ones AFIK.
You mean IO-flexpages and the like? Or do you think of a higher-level implementation language and a modular kernel design which allow to verify the kernel? Well. Best regards, Jork
>>>>> On Sat, 15 Mar 2003 11:31:43 +0100 (CET), Jork Loeser <jork@os.inf.tu-dresden.de> said: JL> Gernot, >> > - Fiasco implements a little more security, especially in relation to >> > task ownership. >> Is "a little more security" similar to "a little bit pregnant"? >> >> I don't think either has a real security model implemented. Most of >> the V2 kernels (x86, Alpha, MIPS) have it, but none of the later ones >> AFIK. JL> You mean IO-flexpages and the like? Or do you think of a higher-level JL> implementation language and a modular kernel design which allow JL> to verify the kernel? Well. I mean clans & chiefs (or replacements), the basic security mechanism in L4. I'm not aware of any post-V2 kernel implementing such basic communication control. Gernot -- Gernot Heiser School of Computer Sci. & Engin. Professor of Operating Systems The University of NSW Phone: +61 2 9385 5156 UNSW SYDNEY NSW 2052, Australia Fax: +61 2 9385 7348 http://www.cse.unsw.edu.au/~gernot
participants (7)
-
Cristiano Ligieri Pereira -
Espen Skoglund -
Frank Mehnert -
Gernot Heiser -
Jacob Gorm Hansen -
Jork Loeser -
Volkmar Uhlig