- l4-hackers - OS Site

task creation in l4ka
by Jan Doerrenbaecher 29 Jan '04

29 Jan '04

Hi List! I have a some trouble with the task creation in l4ka. What I want/should do, is creating a task within the root task without using the rmgr. That means, I have to copy the text area of the new task in some memory region and I also have to allocate some memory for the stack. After this, I want to create the new task with the `l4_new_task` call. The problem now is, that I only have pointers dependent on the local address space of root task which I can give as input. Since the newly created task has its own address space these pointers are not useful. Anyhow, if I use them, the new task is created and running but while executing its code a page fault occurs, founded in the fact, that the new task is trying to get a page allocated by the root task. Am I barking up the wrong tree? Are there any simple solutions for that? Hoping for helpful hints.... Best regards, Jan

2 1

Build DROPS on debian testing
by Frank Matthieß 21 Jan '04

21 Jan '04

i want to take a look on fiasko, drops, dope and get via cvs -d :pserver:guest@os.inf.tu-dresden.de:/home/remote-cvs checkout oskit oskit10 l4env linux22 l4 the latest source. With the "Building DROPS HOWTO" from may 2003 i startup. The "make" run described in "1 Quickstart - 3." failed, because the dependency to automake wasn't mentioned in "3.2 OS requirements". Now make breaks with: ... Making all in dce make[7]: Entering directory `/usr/local/src/drops/l4/tool/dice/src/parser/dce' byacc -pdce -d -v parser.yy && mv y.tab.c parser.cc byacc: e - line 114 of "parser.yy", syntax error %pure_parser ^ make[7]: *** [parser.cc] Error 1 make[7]: Leaving directory `/usr/local/src/drops/l4/tool/dice/src/parser/dce' make[6]: *** [all-recursive] Error 1 ... ii gcc 3.3.2-2 The GNU C compiler ii make 3.80-4 The GNU version of the "make" utility. ii binutils 2.14.90.0.7-3 The GNU assembler, linker and binary utiliti ii bash 2.05b-12 The GNU Bourne Again SHell ii mawk 1.3.3-11 a pattern scanning and text processing langu ii sed 4.0.7-3 The GNU sed stream editor ii perl 5.8.2-2 Larry Wall's Practical Extraction and Report ii flex 2.5.31-21 A fast lexical analyzer generator. ii byacc 1.9.1-1 The Berkeley LALR parser generator ii doxygen 1.3.4-0.1 Documentation system for C, C++ and IDL. The full make log is available here: http://lug-owl.de/~frankm/drops/make.log.l4.20040117-2115 Is their any fix available? Frank. -- Frank Matthieß "Perl looks the same before and after rsa." -- unknown author

3 4

Some question about l4, l4ka
by Frank Matthieß 20 Jan '04

20 Jan '04

Hi, i want to evaluate l4. The first problem i have is to chose the 'right' l4 version. * There is a Dresden version "l4 v2" There is a Karlsruhe version "l4 x.2" * L4Linux is available from Dresden als 2.2.x L4Linux is available from Karlsruhe als 2.4.x Both seems to run on both l4 ipc protocolversion. * At Dresden they have basic parts of os specific components, called DROPS. Also a implementation of an windowmanager (DOpE). At Karlsruhe i don't see any additional os specific components at all. * The L4Ka seems to be the base for ports to other hardwareplatforms, like PowerPC, MIPS etc developed at UNSW. My problem is, to understand the difference/commons in - priority of development of this parts on Dresden and Karlsruhe. - collaboration between Dresden, Karlsruhe and UNSW. If a newbie like want to start, which is the 'right' l4 version and why is it the 'right' version. Frank. -- Frank Matthieß [x] Nail here for new monitor.

1 0

ANNOUNCE: L4Linux 2.4
by Volkmar Uhlig 13 Jan '04

13 Jan '04

The L4Ka team is pleased to announce the availability of L4Linux 2.4, which is a deprivileged Linux kernel running on an L4 microkernel. The release contains support for the L4Ka::Pistachio and Fiasco kernels. It supports the IA32 architecture and features multi-processor support on L4Ka::Pistachio. L4Linux is available via anonymous CVS. L4Linux is for the L4 developer community, and operating systems researchers and developers at large. L4Linux offers a great environment in which to develop and research with L4 microkernels. It offers the support infrastructure of Linux, yet the advantages of the L4 microkernel. This release should not be used in production environments nor for performance evaluations. For more information about L4Linux go to o http://l4linux.org/2.4/ o http://l4ka.org/projects/l4linux/ The L4Ka team

1 0

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 07 Jan '04

07 Jan '04

> -----Original Message----- > From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] > Sent: Tuesday, January 06, 2004 11:07 AM > > BTW, the perception that Jochen Liedtke considered speed to dominate > everything else (see some earlier email) is simply rubbish. > Jonathan's statement "that performance cannot be used to justify > fundamental insecurity" could as well originate from Jochen Liedtke. The hitserver is an example where this perception is not rubbish (as you phrased it). The point I tried to make is that if you want generality of the kernel you have to look at a wide area of applications. As I stated in previous emails, I'm aware of the insufficiencies of the security model in L4 and I believe that this is well taken care of by many people looking at. The same is not true for the performance aspects and my feeling is that "all these important security features" are used to fatten and to slow the kernel unreasonably. Since you referred to Jochen here a quote from "Improving IPC by kernel design": "IPC performance is the Master. Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted." So far there is no sound model proposed which doesn't add significant overhead and which has the same elegance as L4 today. - Volkmar

4 3

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 06 Jan '04

06 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 9:31 PM > > I believe that I have now asked twice for a URL to this specification. > Can you send me a URL? Otherwise we will continue to waste > each other's > time. Please accept my apologies that, in the absence of this > document, I may have done so. > > If it was on one of the L4 web sites, I failed to see it. On the l4ka.org homepage is a link to the latest snap shot (right now rev. 5), or use that link: http://l4ka.org/projects/pistachio/l4-x2-r4.pdf. The V4 spec is solely maintained in Karlsruhe. > > You immediately run into replacement policy issues. > > If there is a faster way, great! But protection is not merely > a desire. It is a hard requirement. *Every* mechanism I know > about for achieving a protected interface carries a fundamental > cost somewhere. You can do it with address space traversal, or > you can accept the need for a replacement policy, or you can do > something else, but you are going to pay *somewhere*. Or you are able to selectively choose to pay for it. > My problem is that performance cannot be used to justify fundamental > insecurity. Speed at the cost of correctness is simply unacceptable. Agree in general, however there are application domains which don't want to give up speed for an unused security model. And you have to accept that those apps exist, even if _you_ are not interested in those. > > Here the argument is around IPC redirection (which is arguably > > expensive). By sticking an interceptor in between you know which > > mappings go in and out. That way you can control it. But I suspect > > that fine-grain control over mapping privileges makes sense. The > > question is what this granularity should be--page or mapping in general. > > From a security perspective, the problem is with the > presence of mapping operations at all. Mapping establishes a > high-speed, mutable channel, so it tends to undermine reference > monitors. Of course you can't allow to permanently establish a page mapping but have to interpose it. However, nobody promised to have a protocol-transparent reference monitor using page mappings.... > My preferred model is that performing a send with a mapping on a > disabled descriptor would be treated as an access violation, and a > suitable exception would be delivered to fault handler. I > don't want to pay any indirection cost for the legal (non-mapping) IPCs. See above. > > You can transparently drop the mapping if it is not > allowed. Since the > > guarantees whether a page is mapped or not come from the > pager hierarchy > > it is only as strong as all combined pagers. By adding a > > non-guaranteeing pager in the hierarchiy you are set. > > >From a security perspective, failing silently is *always* a > mistake. It > also makes virtualization difficult if somebody wishes to be backward > compatible with the interface later. You are describing a situation in > which a sender has done a known-illegal operation, but no fault is > generated? This doesn't seem like a good design. Why? You fault again--the client broke the protocol. You can define a protocol which does not allow page mappings. If anybody tries--too bad. Why do you care about virtualization and what virtualization do you have in mind? (I think it is more a Q of transparency.) > It is a big problem for the pager to be settable by the thread. There > are some systems in which this can be permitted, and other systems in > which it **must not** be permitted. Because there exists systems in > which this must not be permitted, the operation must (at a minimum) > involve invocation of a trusted party. > > Perhaps there is some third design possibility that I have not > considered carefully enough, but it appears to me that a > high-assurance system constructed on top of L4 must be built > exclusively using trusted pagers. While it is possible, in abstract, > to use untrusted pagers in a descriptor-based system (as EROS does), > the L4 map/grant operations don't appear to provide enough book-keeping > controls to be trusted. I guess you have to give a little more information about that--maybe on a whiteboard. It is neither clear to me why this is a *must* nor why an untrusted pager causes a problem. A Q regarding your hash/cache suggestion: how do you ensure that you can't use the cache as a covert channel without major performance losses? - Volkmar

2 1

L4 and EROS
by David Denny 05 Jan '04

05 Jan '04

I have been wondering why "Eros" has invaded this list. This user's pov: L4 is a solid product which works well. I want to experiment with OS building and L4 has a robust base structure, as well as a friendly community and all the tools I need to stick my own silly things on top of it. I support L4. [ I'd support Eros if it had been built to the same level, never mind whatever "angels on pinhead" theoretical issues might occasionally surface. However, from my assessment of the website and some googled papers, Eros is still (shall we say) alpha.] I'm concerned that this side debate might end up destabilising the L4 Team's motivation. [ Actually, I think I meant to include the word "angry" somwhere in there but that would have been out of keeping ] I'm sure that one day there will be viable alternative u-kernels but for the next year or so I can't see anything toppling L4. Please keep at it, Team, and don't allow yourselves to get tr*lled into distractions. And for the moment Happy New Year L4Hackers and please persevere. You are Doing The Right Thing. best wishes David Denny

3 4

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 05 Jan '04

05 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 4:56 PM > To: Volkmar Uhlig > Cc: rudykoot(a)mithrill.org; L4 Hackers List > Subject: L4, High Assurance, and Protection > > Issue 1: Need for Protected IPC > > On Thu, 2004-01-01 at 18:09, Volkmar Uhlig wrote: > > If it does not matter where the check code is executed > > (client/kernel/server) but only who gets accounted for the used > > resources (CPU, cache, whatever) this is not the case. (I'm not > > claiming L4 can do that (yet).) > > In answer to Volkmar's question: it matters very > fundamentally where the > check is performed. It is the difference between mandatory and > discretionary controls. > > The current L4 IPC is discretionary: the sender can invoke anyone, and > the recipient checks the sender identity and decides whether to accept > the IPC. > > In such systems, it is a fundamental requirement that the reference > monitor be able to PREVENT (absolutely) communication between > processes that are under its control. If a sender S is not > permitted to send to a recipient R, the behavior must be exactly > as if the send was performed to a non-existent ID. Ok, I see that point. > The main change that is needed in L4 to resolve this is to define the > recipient-id and sender-id fields as opaque fields. Under > high-assurance requirements, the sender is not entitled to know how > many threads execute within the recipient. The sender-id and > recipient-id therefore must not encode "thread within process". > Similarly, it must not encode "process ID". I think there is some misconception around about L4's thread ids. In L4 V4 (X.2 is going to become V4 after maturing) threads and address spaces are completely independent of each other. Threads execute in an address spaces, but they can migrate. A thread ID is a communication-endpoint place holder. If you have, say, 100 threads in an address space and you want to hide that fact you can use a single thread serving as a distributer. Since we have local IPC the distribution can completely take place in user land without a kernel invocation. The worker can impersonate the distributer for the reply. > While I do not advocate any particular implementation strategy, let me > give an *example* of one that might suffice: a simple hash table. > Instead of using the PCB address as the process ID, the > kernel could use > H(sender kernel ID, requested-recipient-ID) as an index into a hash > table and perform a single indirection (and possible hash bucket > chasing) to find the process address. This is fundamentally the design > proposed by Trent several years ago. You immediately run into replacement policy issues. > 2: Restricted Mapping > > This is a very small issue, and there may be some way around it. > > In general, I like the map/grant model very much, but in some > systems it is necessary for the manager to know who has what mappings. > In these systems, having applications perform mappings directly to each > other creates a consistency problem. Here the argument is around IPC redirection (which is arguably expensive). By sticking an interceptor in between you know which mappings go in and out. That way you can control it. But I suspect that fine-grain control over mapping privileges makes sense. The question is what this granularity should be--page or mapping in general. > My preference would be to have *both* controls, because they serve > slightly different purposes. The first lets me virtualize the > map/grant operations (in order to keep manager metadata updated), > while the second prevents map recursion. > > The problem with the first method is that it requires protected > recipient descriptors. You can transparently drop the mapping if it is not allowed. Since the guarantees whether a page is mapped or not come from the pager hierarchy it is only as strong as all combined pagers. By adding a non-guaranteeing pager in the hierarchiy you are set. > The problem with implementing only the second method is: what > thread id should a page fault handler receive from a faulting thread? > Restricted or non-restricted? I can argue for either depending on what > kind of system I am trying to build. That raises the question whether the pager is privileged or not. Since the pager can be set by the thread the pager can be changed and the thread could elevate its privileges. Or did I misunderstand you? - Volkmar

2 1

RE: IPC/Capabilities Overview
by Rudy Koot 05 Jan '04

05 Jan '04

>That is wrong. The direct lookup drastically reduces cache and TLB >footprint. For a full IPC we have to access two TCBs (which are >virtually mapped and have the stack in the same page) which costs two >TLB entries. The complete lookup is therefore a simple mask (plus maybe >a shift), a relative mov (e.g. mov 0xe0000000(%eax), %ebx) and a >compare. Overall costs therefore (on IA32): >- 2 TLB entries (but we need them anyway for the stack, they could be >reduced to one TLB entry when using 4M pages for all TCBs, but that >would add an indirection table and therefore a cache line); refetch >costs ~80 cycles/entry >- shift and move (~3 cycles) >- 1 cache line for the thread id (which is shared with thread state >etc). > >Assume you add 2 more TLB entries and 5 more L2 cache lines--your >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. >Considering overall IPC costs of 1000 cycles on a P4 with all those >nasty cache and TLB flushes you add an overhead of >50%. The "but we need them anyway for the stack, they could be reduced to one TLB entry when using 4M pages for all TCBs, but that would add an indirection table and therefore a cache line" part seems very interesting, I've seen something about it in your microkernel presentations, so I guess you have done some speed measurements. Now if you would give each address space it's own indirection table, you would have a thread space. Have you done measurements? What does this methode cost? -- Rudy Koot _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl

2 1

RE: IPC/Capabilities Overview
by Volkmar Uhlig 05 Jan '04

05 Jan '04

Similar to Rudy I try to answer multiple mails at once. (Sorry for the long post!!!) First a general statement. It appears to me that goals are very different. As Rudy pointed out one of the main goals of L4 (at least pursued in Karlsruhe) is to have a universal and high performance uK. Universal here means that it is applicable to any domain. That also answers Rudy's question who is going to use a microkernel without a security model--anybody who does not require a security model. And that may be your wrist watch, cell phone, or a medical appliance. Jonathan wrote: > Please consider that "clever" is a four letter word (a curse). All of > these optimizations are, in my opinion, justifiable reasons to fire a > programmer with a strongly negative recommendation. The resulting > systems are unmaintainable. > > Speed is not the primary goal. Efficient robustness (measured end to > end) is the primary goal. That maybe true for your research agenda. However, to investigate the limits of uK based systems I would be very disappointed if you wouldn't even consider these optimization. Then we are back to the good old MACH problem: uKs are inherently slow by nature, full stop. And, we are talking research here, not business (btw, I would fire those guys too). We may also simply not have the right tools to do that robust and efficiently today, but then we should look into better tools. > Excuse me, but this is utter nonsense. You are making a quantitative > argument using qualitative and unsubstantiated arguments. You (and I) > need numbers in order to evaluate this issue. > > The correct way to approach this is to ask: > > 1. What percentage of invocations dynamically incur the cost of > checking? > 2. What is the respective cost of this checking at user and at > supervisor level? > 3. Given that the supervisor-mode implementation *is* incurred by > all cases, what is the weighted cost of the mechanism in both > cases (user and supervisor). > > Once you have this calculation, you have a correct > engineering basis for making a decision. Good that we are on common ground now. We also have to agree on what system you and I have in mind and from that we can derive the overall costs. To me it seems you are implying a system design and claim that L4's lack of certain features makes it perform as good/bad or worse. However, by not having the feature in the kernel but in user land allows to modify it. Now the question changes to how efficiently can we implement it in user land compared to the in-kernel version. In the case it is part of the kernel you can't change it anymore which means you will always pay the cost whether you want or not. And here you also have to evaluate _all_ potential systems, even those without security requirements. > And I should acknowledge that I disagree with Volkmar very > fundamentally about the "performance uber alles" assumption. > Performance is important, but from a research perspective it > is *more* important to understand what the fundamental architectural > issues are. Once we do, we can step back and decide what to take > out. At the moment, we have no common base on which direct comparison > is possible. I think Jonathan misunderstood me on that. I think we have a set of core requirements for a kernel which are probably almost identical for EROS and L4. However, we have a different focus. And performance is still one of the main reasons why monolithic kernels are preferred over uKs. That does not mean that security is less important. > I don't think that the L4 kernel has all the answers, but I also think > that the EROS kernel does not have all the answers. Each, I think, has > important strengths. EROS lacks a certain elegance of minimality. L4 > (as I understand it today) lacks a credible story about security, access > control and denial of service. Perhaps it is time for both groups to > step back and make a serious attempt to learn from each other. I agree that one of the current weaknesses of L4 is its very rudimentary security model. And each L4 group seems to have its own perspective on how this should be solved. > From the conversations on this list, however, it appears to > me that the L4 research groups do not agree universally on what the > IPC control mechanism is, and this may be contributing to some > difficulty in the discussion. One group clearly advocates thread spaces. > Volkmar (if I understand him) currently advocates IPC indirection. The > two designs have very different implications for performance, implementation, > and security. No, I'm not advocating this. So far nobody has a reasonable cost-benefit analysis of the thread mappings and as long as that is the case I'm not in favor of anything. However, considering complexity and elegance of the different alternatives and the performance impact on a wide variety of hardware architectures (specifically MP and NUMA systems), I'm very skeptical about proposals which bind security principals on address spaces. That will just open another can of worms. The redirection model has the disadvantage of fundamentally changing the semantics of IPC. With a purely synchronous IPC model timing is a fundamental part of the communication protocol. Transparent interception is not possible since the message gets successfully delivered to the redirector, which, however, may discard it. This alters guarantees usually given by the kernel. > Volkmar's technique is quite elegant. The only problem I see > is that it places the burden of verification on the wrong party > -- it should be on the client. That is, the design invites DoS > attacks. If it does not matter where the check code is executed (client/kernel/server) but only who gets accounted for the used resources (CPU, cache, whatever) this is not the case. (I'm not claiming L4 can do that (yet).) > However, Volkmar is making an assumption that is problematic. He is > assuming that the passed ID is a pointer. From a security perspective > this is VERY bad. First, it invites memory attacks. Second, > it discloses information about the internal implementation of the server. > Third, it makes selective rescind of authority very hard to do. No, it can be an object handle which can be translated in some/any way (e.g. cryptographically modified, or a hash). The fundamental difference is that it is not a first class kernel object. This means you have the freedom to choose the appropriate encoding (which could be a pointer of course). > As a backwards compatibility matter, and as a validation of the L4 > nucleus, running Linux on an L4 is interesting. As a matter of future > research, and as a matter of forward-looking system > architecture, it is boring. Yes, I agree. However, a gradually decomposed Linux can answer many research questions without re-implementing a fully fledged OS. > The right forward-looking research question is: > > *Given* a fast nucleus in the style of L4, what is the most > effective way to structure a native operating environment? > What fundamental and novel leverage do such kernels provide? That was one of the goals of SawMill. ==== Rudy wrote: > Sorry, but I do not see how the version part could be used as > the server defined word. You can't have multiple versions > (read server defined words) of the same thread-id at the > same time. Correct. I had a different usage scenario in mind--sorry for confusions. > I believe these costs are exagerated. To convert a capability into > sender-id a simple table lookup can be used. This requires a single > TLB entry and a single L2 cache line (worst case). If IPC is frequent, > which is the case in which you want high performance, the TLB entry > is very likely to be present and probably even the L2 cache line. This assumes that you have a small TLB working set and small cache working set. However, if communication is frequent that also means that you are probably communicating to _many_ partners. And then you probably need a TLB entry per table which again increases the TLB footprint. That means the likelihood that you replace user-TLB entries goes up--the problem is the user's active working set you replace. ==== Jonathan wrote: > Volkmar is combining two things in one, and seems to be > forgetting that he does so. You are correct. Once you have the > capability, obtaining the target thread id is quite fast. No table > lookup is required. The capability is kernel-protected state, and can > simply contain a direct pointer to the recipient PCB. > > I think that the costs that Volkmar is identifying come from > the need to lookup the thread-id or capability in the thread mapping > space. That is, these are the costs of the address space traversal. > The costs are the same in either case (thread-id or capability). If you add a level of indirection (thread id or cap) that is the case. However, if you pay for a level of indirection anyhow, then it does not matter whether the name specifies a capability or a thread. I have the (maybe unreasonable) feeling that it should be possible to express both in one model with the same costs associated. > One of the features of EROS is an indirection object. This object can > stand in front of a start capability transparently. The client invokes > the indirection object capability rather than the start capability. > Given this construction, a service can selectively rescind that client > capability by destroying the indirection object. > > This is something that L4 presently has no means to do. Of course, L4 > does not need it, because it makes no assumption about controlling > client invocations at all. In the current L4 model this would be a proxy thread assuming that IPC is cheap and it happens infrequently. In the case of frequent redirection you would extend the IPC protocol to take the reconfiguration into account. This boils down to how much transparency do we want. Jonathan mentioned on the EROS list that transparent persistency is something which is not feasible. The same question can be asked in this case: is transparent redirection something we want/need? And are we willing to pay the overhead? One could construct a system, where communication can only be restricted (for enforcement) and apps must be able to dynamically re-configure. ==== Jonathan > In practice, I would use a cache for an L1 software probe > first in order to avoid all marginal TLB and cache misses > in the usual case, but this would result in high variance > of IPC times. Which means you add a new policy to the kernel, something we strictly try to avoid with L4. - Volkmar

2 2

RE: IPC/Capabilities Overview
by Volkmar Uhlig 04 Jan '04

04 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Wednesday, December 31, 2003 6:32 AM > > First, some corrections on specific statements that you made, because > they are potentially distracting from the real issues. Then I will try > to answer your questions. > > Corrections: > > 1. L4 IPC speed has relatively little to do with the "direct lookup" > aspect of thread ids. Any indirect encoding will carry a cost, but in > terms of the overall performance of IPC this cost is quite small. That is wrong. The direct lookup drastically reduces cache and TLB footprint. For a full IPC we have to access two TCBs (which are virtually mapped and have the stack in the same page) which costs two TLB entries. The complete lookup is therefore a simple mask (plus maybe a shift), a relative mov (e.g. mov 0xe0000000(%eax), %ebx) and a compare. Overall costs therefore (on IA32): - 2 TLB entries (but we need them anyway for the stack, they could be reduced to one TLB entry when using 4M pages for all TCBs, but that would add an indirection table and therefore a cache line); refetch costs ~80 cycles/entry - shift and move (~3 cycles) - 1 cache line for the thread id (which is shared with thread state etc). Assume you add 2 more TLB entries and 5 more L2 cache lines--your aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. Considering overall IPC costs of 1000 cycles on a P4 with all those nasty cache and TLB flushes you add an overhead of >50%. > 2. Security checks done in the server vs. the kernel are not > necessarily slower or faster. It depends greatly on what security > checks you wish to do. I argue that: > > a) *many* (not all) of the security checks currently done in L4 > servers could be eliminated if kernel-protected bits existed > in each descriptor > > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal > microkernel. > > c) More specifically, any microkernel that requires checks based > on sender-id is entirely unsuitable as a platform for EROS-NG. And as you stated this is _also_ a limited view, because you only look from the EROS and capability point of view. By throwing away one register for an identifier you reduce your register real estate by 33%. That can be particularly hurtful in the local case, where a very simple check (or none) is sufficient. And the argument that everything should go in memory (one of your last emails) is not convincing--register-based IPC is still much faster, it is mostly a question of a reasonable IDL compiler. And we are all aware that IA32 is crippled from that perspective. Take any other architecture (worst case: IA64) and the argument becomes complete bogus. > Ignoring clans and chiefs (which we all agree is too expensive and > inflexible), here is how the three schemes break down: > > Thread IDs: > No restriction who can send. > Server makes decisions based on sender-id You forgot sender restriction and redirection. > Hybrid: > Sender can only invoke a thread descriptor that is mapped in their > thread descriptor space (thread space) > Server makes decisions based on either (a) a field that is encoded > within the descriptor, or (b) the sender-id. > > ** Sender-id is software controlled by the thread manager, and can > be set to zero for all threads to simulate capability behavior. A possibility you did not mention is a hybrid thread id which has an thread and a descriptor part. The descriptor is kernel enforced. That is what we currently have in V4 (please not that V2 and X.0 are completely outdated!!!)--the version part of the thread id. > In the thread-IDs design, there are two distinguished phases in the > server-side security checks: > > 1. Object resolution. Based on sender-id and arguments, determines > the identity and permissions of the server-implemented object > that has been invoked. This phase may conclude that no such > object exists. > > 2. Permissions check. Given the object identity and permissions, > make a decision about whether the particular operation is to be > permitted. > > All of the bits needed for phase 2 can be encoded in the > descriptor. All of the expensive parts of the current L4 protocol > lie in phase 1 (object resolution). See above. Furthermore, your suggestion is to move that part into the kernel... Then the overhead is on _every_ invocation, not just for the once where you need it. > > Now I want to make clear why capablities are much better > than virtual thread > > objects: > > > > * The extra word does not seem to decrease performance in > any way (is this > > true?) so it a free feature, that can be used but doesn't have to. > > I believe that this is true, and the evidence of the EROS > implementation seems to support this view. Where are benchmarks with cold caches? Do you have a detailed analysis of the cache and TLB footprint? > This is a possible usage. In our experience, the more common > behavior is > to have a pointer to some data structure that describes a server > implemented object (i.e. has nothing to do with any > particular client), > and reuse the low bits for permissions. For example, the pointer might > point to a file metadata structure, and the low bits might > indicate read and write permissions. In our case we use an object identifier in the message, which is a handle to an object descriptor and do a reverse check (i.e. if the thread is allowed to invoke that object). Costs: boundary check (can be a simple AND) one MOV and a CMP. The permissions can go into the same cache line. Happy new year!!! - Volkmar

4 3

Re: IPC/Capabilities Overview
by Jonathan S. Shapiro 02 Jan '04

02 Jan '04

On Thu, 2004-01-01 at 02:56, Rudy Koot wrote: > Some comments and questions to about 5 different e-mails: Some answers, as best I can. :-) > ===== Rudy > > Some of Volkmar's arguments are based on the fact that L4 is a general > purpose microkernel, I think the discussion would be more useful if we look > at how a microkernel with the purpose of running a capability based system > on top, should be design. Leaving the question wheter those capabilities > should be implemented at kernel-level or user-level open. We already have that kernel. It's called EROS. While I do know how to build a variant that is much closer in spirit to L4 (i.e. smaller -- we designed such a nucleus at IBM) I do not believe that its end to end performance will be any better. However, I have been very carefully avoiding the direction you identify for three reasons. The first is that I deeply respect the L4 work. The second is that I attempted a successor to L4 after Jochen left IBM and it became a bit sensitive. The third is that the L4 group has not chosen to pursue capability-based design, and I am not interested in redirecting their work. At this time, what I am trying to achieve is a common nucleus on which both teams can pursue their research. This will facilitate cross-fertilization of ideas, and I believe that this will benefit both groups. The plain fact is that the L4 and EROS communities can successfully proceed in independent directions, each lacking a critical mass of people. I do not believe that this is the most productive way to proceed. And I should acknowledge that I disagree with Volkmar very fundamentally about the "performance uber alles" assumption. Performance is important, but from a research perspective it is *more* important to understand what the fundamental architectural issues are. Once we do, we can step back and decide what to take out. At the moment, we have no common base on which direct comparison is possible. I don't think that the L4 kernel has all the answers, but I also think that the EROS kernel does not have all the answers. Each, I think, has important strengths. EROS lacks a certain elegance of minimality. L4 (as I understand it today) lacks a credible story about security, access control and denial of service. Perhaps it is time for both groups to step back and make a serious attempt to learn from each other. > ===== Rudy > > Any form of IPC in which the decission to allow or disallow a thread to send > a message to another thread is vulnerable to a DoS attack. If the decission > is mad by the kernel the IPC can be canceled immediately, but if it is made > at user level another thread is blocked for a small amount of time. This is exactly true, but it fails to take into account the fact that IPC indirection can possibly suppress this behavior. I do not understand the current IPC indirection proposal, and trying to reason without understanding it is very slippery. Also impolite. Something I am known for, but I do try not to do it on purpose. :-) >From the conversations on this list, however, it appears to me that the L4 research groups do not agree universally on what the IPC control mechanism is, and this may be contributing to some difficulty in the discussion. One group clearly advocates thread spaces. Volkmar (if I understand him) currently advocates IPC indirection. The two designs have very different implications for performance, implementation, and security. > ===== Shap > > > b) For some types of systems (capability systems), disclosure of > > the sender id is an absolute violation of design requirements, > > so any microkernel that relies exclusively on server-side > > security checks based on sender-id is not a universal microkernel. > > Sorry, but you still owe me an example of a situation in which revealing the > sender-id actually breaks the security of the system. The only thing I could > think of was that it might reveal some details about the internal structure > of an application, but if the system is secure that information hasn't got > much use to a malicious program or user. >From the perspective of security you are reasoning backwards. There is never a mandate to justify withholding information. The mandate is always the other way: if you wish to argue that a sender-id is desirable, you must justify why its disclosure is safe and also why it is required. Observation: it is not, and it is not. In answer to your question, here are some problems with disclosing sender ID: 1. The one you mentioned: it discloses client structure, which is something that the server is not entitled to know. 2. It mandates a client structure, because using the sender-id as a credential strongly discourages the application developer from breaking their applications into multiple address spaces and separate threads. This defeats robustness and security both. 3. It is inaccurate. The server can NEVER rely on the sender-id, because it cannot know if the immediate sender is acting in proxy for someone else. That is, sender-id can only provide false security. Personally, I find (2) very ironic. Ultimately, the main justification for fast IPC is that it makes decomposed applications easier. I find it curious, given this, that L4 adopts an access checking model that defeats decomposition. I also find it very curious that no L4-based system (at least, none that I know about) has really pushed for fine-grain decomposition. Perhaps Mungi did and I do not understand it well enough. As a backwards compatibility matter, and as a validation of the L4 nucleus, running Linux on an L4 is interesting. As a matter of future research, and as a matter of forward-looking system architecture, it is boring. The right forward-looking research question is: *Given* a fast nucleus in the style of L4, what is the most effective way to structure a native operating environment? What fundamental and novel leverage do such kernels provide? That is: do fast IPC and microkernels provide anything that is architecturally important, or are they just clever tricks that are good only for conference papers? Obviously, I believe that they are useful. The problem I see is that *none* of our groups are big enough to successfully evaluate this question of "what native environment?" It requires a truly awesome amount of work. > I really think this is an important point. If revealing the sender-id is > indeed a violation of security, there wouldn't be a need to discuss wheter > or not thread-spaces need to be implemented. They just have to. > > > c) More specifically, any microkernel that requires checks based > > on sender-id is entirely unsuitable as a platform for EROS-NG. Because (a) revealing sender-id is a security hole, and (b) EROS is a capability system. The latter is a matter of definition. > >Assume you add 2 more TLB entries and 5 more L2 cache lines--your > >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. > >Considering overall IPC costs of 1000 cycles on a P4 with all those > >nasty cache and TLB flushes you add an overhead of >50%. > > I believe these costs are exagerated. To convert a capability into sender-id > a simple table lookup can be used. This requires a single TLB entry and a > single L2 cache line (worst case). If IPC is frequent, which is the case in > which you want high performance, the TLB entry is very likely to be present > and probably even the L2 cache line. Volkmar is combining two things in one, and seems to be forgetting that he does so. You are correct. Once you have the capability, obtaining the target thread id is quite fast. No table lookup is required. The capability is kernel-protected state, and can simply contain a direct pointer to the recipient PCB. I think that the costs that Volkmar is identifying come from the need to lookup the thread-id or capability in the thread mapping space. That is, these are the costs of the address space traversal. The costs are the same in either case (thread-id or capability). If the kernel implementation uses flexpages, then I believe that in the usual case the reality will be only one TLB miss, but the number of L2 references seems plausible and problematic. In practice, I would use a cache for an L1 software probe first in order to avoid all marginal TLB and cache misses in the usual case, but this would result in high variance of IPC times. > >In our case we use an object identifier in the message, which is a > >handle to an object descriptor and do a reverse check (i.e. if the > >thread is allowed to invoke that object). Costs: boundary check (can be > >a simple AND) one MOV and a CMP. The permissions can go into the same > >cache line. Volkmar's technique is quite elegant. The only problem I see is that it places the burden of verification on the wrong party -- it should be on the client. That is, the design invites DoS attacks. However, Volkmar is making an assumption that is problematic. He is assuming that the passed ID is a pointer. From a security perspective this is VERY bad. First, it invites memory attacks. Second, it discloses information about the internal implementation of the server. Third, it makes selective rescind of authority very hard to do. One of the features of EROS is an indirection object. This object can stand in front of a start capability transparently. The client invokes the indirection object capability rather than the start capability. Given this construction, a service can selectively rescind that client capability by destroying the indirection object. This is something that L4 presently has no means to do. Of course, L4 does not need it, because it makes no assumption about controlling client invocations at all. > >A possibility you did not mention is a hybrid thread id which has an > >thread and a descriptor part. The descriptor is kernel enforced. That > >is what we currently have in V4 (please not that V2 and X.0 are > >completely outdated!!!)--the version part of the thread id. > > Sorry, but I do not see how the version part could be used as the server > defined word. You can't have multiple versions (read server defined words) > of the same thread-id at the same time. I don't either, but I don't understand what Volkmar is proposing enough to comment intelligently. I would like to, and I hope he will respond with a pointer to a specification or more detail about where these references are occuring. I am not sure that I have understood him correctly. shap

2 2

Re: IPC/Capabilities Overview
by Rudy Koot 01 Jan '04

01 Jan '04

>Corrections: > >1. L4 IPC speed has relatively little to do with the "direct lookup" >aspect of thread ids. Any indirect encoding will carry a cost, but in >terms of the overall performance of IPC this cost is quite small. While this is indeed also my believe, it unfortunately isn't that of the L4 team. If you look at their presentation their two main points are: "IPC needs to be infinitly fast". The problem is that they only look at direct costs of cycles spend on entering the kernel, doing IPC and exiting tthe kernel. They also look at indirect costs of TLB and cache misses caused by IPC, but strangely enough won't look at the cost of checking access rights (probalby because access checks are no longer part of the microkernel, but of operating system policy). If you want to convince them, you have to make sure they eiter count those costs also OR make sure they believe the added IPC costs of capabilities are indeed neglectable. As far as I could reason these added (compared to the thread-id methode) costs would be: - One extra register spilled on the receiver side (to store the server defined word) - One extra memory access (to convert the capability into the server thread id) [VTO] - One extra memory access (to load the server defined word) - One or more extra memory accesses (to locate the server defined word and server thread id in the Thread Object Space) [VTO] This goes in against their believe that "A computers get faster memory acess get relativly slower, therefore memory access should be avoided during IPC". I believe only 2 memory accesses are needed on RISC machines with large register sets, so the 3+ extra accesses are quit a burden (through the L4 developer's eyes). However they are considering Virtual Thread Objects and compared to that only 1 extra memory access is required (this isn't a lost comparing against the 4+ that already need to be done), because the steps marked with [VTO] needs to bee done in that model also. > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal microkernel. I never realised this, and I still don't see why this a design requirement, but if there is one this would again be a major argument in favor of capabilities. Could you give me an example of when not reveiling sender-id is useful? >Hybrid: > Sender can only invoke a thread descriptor that is mapped in their > thread descriptor space (thread space) > Server makes decisions based on either (a) a field that is encoded > within the descriptor, or (b) the sender-id. > > ** Sender-id is software controlled by the thread manager, and can > be set to zero for all threads to simulate capability behavior. Could you explain a bit more about this thread manager. It seems to solve a problem in which the sender id does needs to be know. For example if a thread tries to write to a file, which it hasn't got write access for, it may be a system requirement that this is logged into the security log. Now you also want to log which thread actualy made the violation. If the sender-id isn't reveiled to the file server it can only log the thread-id (no not thread-id, something else but what?) to which it originally mapped the capability. Maybe if a thread manager is used the true sender-id can be logged withour reveiling it so the file server itself? > > * The server defined word will probably be used to store a pointer to >some > > client specific data structure containing important information that >needs > > to be access often. You might say, yeah well mbut you can calculate this > > address from the sender ID, but this no longer works when clients start >to > > grant and map server objects/capabilites to eachother, because the >server > > doesn't know about these actions, unless some complex, slow protocol is >used > > to update the serves information. > >This is a possible usage. In our experience, the more common behavior is >to have a pointer to some data structure that describes a server >implemented object (i.e. has nothing to do with any particular client), >and reuse the low bits for permissions. For example, the pointer might >point to a file metadata structure, and the low bits might indicate read >and write permissions. I used some strange wording in my explanation but a meant what you just said. > > The size of the > > capability should be equal to the pointer/word size of the machine. > >This can't be true, since the capability must encode both the >destination thread id and also the extra word. Minimum practical size is >two machine words. Sorry this was a typo, I Actually meant to say the size of the server defined word inside the capability shouls be aqeual to the machine word size, making the total capability size, indeed, at least 2 machine words in size. -- Rudy Koot _________________________________________________________________ MSN Zoeken helpt je om de gekste dingen te vinden! http://search.msn.nl

3 3

Re: IPC/Capabilities Overview
by Rudy Koot 01 Jan '04

01 Jan '04

Some comments and questions to about 5 different e-mails: ===== Rudy Some of Volkmar's arguments are based on the fact that L4 is a general purpose microkernel, I think the discussion would be more useful if we look at how a microkernel with the purpose of running a capability based system on top, should be design. Leaving the question wheter those capabilities should be implemented at kernel-level or user-level open. ===== Rudy Any form of IPC in which the decission to allow or disallow a thread to send a message to another thread is vulnerable to a DoS attack. If the decission is mad by the kernel the IPC can be canceled immediately, but if it is made at user level another thread is blocked for a small amount of time. ===== Shap > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal microkernel. Sorry, but you still owe me an example of a situation in which revealing the sender-id actually breaks the security of the system. The only thing I could think of was that it might reveal some details about the internal structure of an application, but if the system is secure that information hasn't got much use to a malicious program or user. I really think this is an important point. If revealing the sender-id is indeed a violation of security, there wouldn't be a need to discuss wheter or not thread-spaces need to be implemented. They just have to. > c) More specifically, any microkernel that requires checks based > on sender-id is entirely unsuitable as a platform for EROS-NG. Why? ===== Volkmar >Assume you add 2 more TLB entries and 5 more L2 cache lines--your >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. >Considering overall IPC costs of 1000 cycles on a P4 with all those >nasty cache and TLB flushes you add an overhead of >50%. I believe these costs are exagerated. To convert a capability into sender-id a simple table lookup can be used. This requires a single TLB entry and a single L2 cache line (worst case). If IPC is frequent, which is the case in which you want high performance, the TLB entry is very likely to be present and probably even the L2 cache line. This is supported by your own description how access checks are done at user level (although this is actually the reverse as you point out, the methode stays the same): >In our case we use an object identifier in the message, which is a >handle to an object descriptor and do a reverse check (i.e. if the >thread is allowed to invoke that object). Costs: boundary check (can be >a simple AND) one MOV and a CMP. The permissions can go into the same >cache line. ===== Volkmar >A possibility you did not mention is a hybrid thread id which has an >thread and a descriptor part. The descriptor is kernel enforced. That >is what we currently have in V4 (please not that V2 and X.0 are >completely outdated!!!)--the version part of the thread id. Sorry, but I do not see how the version part could be used as the server defined word. You can't have multiple versions (read server defined words) of the same thread-id at the same time. ===== Volkmar >- local data structures--or do you want to share your cap-tables on NUMA >systems between processors? How do you plan to memory-manage those? I generaly don't worry too much about performance as long as it scales wth processor speed/count. This argument is indeed a sane one. However I do believe it is possible to use the techiques to gain better performance used at user-level can also be applied to a kernel-level methode. This does bring up another question. How do you memory manage TCBs in L4 on NUMA systems? ===== Volkmar >That is exactly the point. If you add that feature to the kernel you >pay on _every_ system, even if it does not need any security mechansims >at all (or only very rudimentary). Hence, moving it to user land >eliminates it from the critical path and makes other scenarios faster >(without, from my perspective, massively hurting systems which need and >want such security models). Whoch person with a sane mind would want to implement an unsecure operating system on top of a microkernel? That's just not a smart thing to do. The only reason microkernels still exists is because they offermore security and are more flexible. And unsecure systems are also systems that wnat maximum performance (so they don't want to run on top of a microkernel) and for that same reson don't need the flexibility. Unsecure operating systems no longer run on servers, workstations and dektops. They are only used for embedded systems, and those are unlikely to run ontop of L4. -- Rudy Koot _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/

1 0

RE: IPC/Capabilities Overview
by Volkmar Uhlig 01 Jan '04

01 Jan '04

> -----Original Message----- > From: Rudy Koot [mailto:rudykoot@hotmail.com] > Sent: Wednesday, December 31, 2003 11:39 AM > The problem is that they only look at direct > costs of cycles spend on entering the kernel, doing IPC and > exiting tthe kernel. They also look at indirect costs of > TLB and cache misses caused by IPC, but strangely enough won't > look at the cost of checking access rights (probalby because > access checks are no longer part of the microkernel, but > of operating system policy). That is exactly the point. If you add that feature to the kernel you pay on _every_ system, even if it does not need any security mechansims at all (or only very rudimentary). Hence, moving it to user land eliminates it from the critical path and makes other scenarios faster (without, from my perspective, massively hurting systems which need and want such security models). > If you want to convince them, you have to make sure they eiter > count those costs also OR make sure they believe the added > IPC costs of capabilities are indeed neglectable. As far as I > could reason these added (compared to the thread-id methode) costs > would be: > > - One extra register spilled on the receiver side (to store > the server defined word) > - One extra memory access (to convert the capability into the > server thread id) [VTO] > - One extra memory access (to load the server defined word) > - One or more extra memory accesses (to locate the server > defined word and server thread id in the Thread Object Space) [VTO] And you forgot all the TLB entries you need. When moving it to user land you are able to optimize the lookups by: - clever choosing identifiers (your identifier space is unlimited and can be as small as zero bits) - efficient and combined lookup strategies (e.g. a file descriptor can contain the filepos and security identifiers) - combined calls, i.e. accessing multiple identifiers at once (write to n files at a time, multicast) - local data structures--or do you want to share your cap-tables on NUMA systems between processors? How do you plan to memory-manage those? - Volkmar

2 1

IPC/Capabilities Overview
by Rudy Koot 31 Dec '03

31 Dec '03

Just to avoid any confusion. Can you tell me if I got this right: There are three possible ways to restict/allow communication between threads, using * Thread IDs (current L4 v4 implementation) Any thread can communicate to any thread and send any message. Access checks need to be done by the server, that might need to verify some things using another 'security' server, requiring another IPC. The IPCs itself are very fast because no table lookups are necessary to verify if the communication is allows. However suity holes are much easier to created by buggy code that forgets to verify some accesses. Additionally the security checks are executed even slower than if they where done inside the kernel as in the other two methodes. These security checks can be done automatically using IPC redirection. This still requires an additional IPC, had some strange (unclean) quircks associated with it and I still doubt wether this methode is secure especially when used by buggy programs. * Virtual Thread Objects (possible L4 v5 implementation) Each thread has a kernel table attached to it (1) which lists the threads it can communicate to. These virtual thread objects can be grranted, mapped and unmapped just like flexpages. So when a message is received the server can be sure it is send by a thread that is mapped it's thread ID to. (1) Threads in the same address space might share the same table. * Capabilities (current EROS implementation) Capabilities are similar to Virtual Thread Objects except that they have a server defined word attached to them. I first want to make clear why the second and third methode are much better than the first: * Methode 1 is insecured when used with buggy programs. The fact simply is that most, if not all, programs are buggy. I agree with shap that the cost of a program should be measured in total resources used (dollars or additional programming time for example) and not just computational resources. * In a system that requires security the 2nd and 3rd methodes are actually faster because only a single, cimple kernel check needs to be made agisnt several complex user checks for methode 1 (is this realy true? comments please). L4 is designed to be secure anyway and is therefore already to slow for systems that don't require security, so the penalty the insecure systems woudl suffer does not apply. * Additional security benefits are that the internal thread structure is not revealed to every program running on the system and some protection against DoS attacks is offered. Now I want to make clear why capablities are much better than virtual thread objects: * The extra word does not seem to decrease performance in any way (is this true?) so it a free feature, that can be used but doesn't have to. * The server defined word will probably be used to store a pointer to some client specific data structure containing important information that needs to be access often. You might say, yeah well mbut you can calculate this address from the sender ID, but this no longer works when clients start to grant and map server objects/capabilites to eachother, because the server doesn't know about these actions, unless some complex, slow protocol is used to update the serves information. My conclusion is that Virtual Thread Objects/Capabilities are far supiror than just using Thread IDs and that the server defined word of Capabilities are very important to manage information of a server. The size of the capability should be equal to the pointer/word size of the machine. Constructive criticism is very much appreciated, Rudy Koot _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/

2 1

Object descriptors vs sender id
by Einar Karttunen 23 Dec '03

23 Dec '03

Hello I would like to make few notes on the recent discussion on Eros object descriptors vs the L4 sender id. Sorry if I have misunderstood parts of the discussion. The main problem is imho how can the sender know the client is entitled to use the service? Eros: - The sender just marks this information inside the descriptor. - Access check is done with a simple comparison - The state is not visible to the client - ipc is a little bit slower L4: - The state is either - visible to the client - the client can mutate it -> expensive checking - the client can pass it to others without supervision - stored inside a non-related thread - instead of two ipc operations we need three (C->S->C becomes C->store-thread->S->C) - stored inside server (more complexity, granting permissions is hard) - All servers need to store client state. - Upon each request we typically need a hash lookup - Clients need to communicate passing descriptors to the server - The pager adds a prefix scheme does not really help as the server does not necessarily trust the clients pager. The following come into mind as problem cases: - A client using thread pool - A permission for all children of a thread (or capabilities in general) Also the Eros model seems to map better to a distributed enviroment. In L4 one would need to allocate one thread per remote client/thread/set of permissions while in the Eros model just hold different capabilities. Modelling L4 with Eros - The server uses a word of data in the descriptor - The kernel fills it with the caller-id (needs hacking) Modelling Eros with L4 - This seems quite difficult to archive without additional lookups. - How can one build a *safe* mechanism on top of L4? - All API based approaches fail because malicious clients can send handcrafted messages. - Einar Karttunen

3 2

RE: Comparing IPC and capability invocation
by Volkmar Uhlig 22 Dec '03

22 Dec '03

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Thursday, December 11, 2003 9:57 AM > > By all means we should discuss, but let me attempt to clarify. > > ALL communications are invocations on objects. The only questions that > exist in principle are: > > 1. What restrictions are imposed on the TYPE of object that can be > invoked? > > 2. Is the object namespace extensible by user-mode code. That is, > can user-mode servers present objects or interfaces that appear > to the invoker to be "first class" in the same sense that kernel > supported objects are first class. > > L4 imposes the restriction that the only invocable object type is > "process" (or in some cases thread). We only have threads, there is no notion of processes (I'm talking about V4/X.2). > L4 does *not* (today) provide means to allow a server to extend the > object name space. There is no reason, "objects" are user-managed things. Allowing extension doesn't bring you any benefit. Transparency can be implemented in a user-level library (without any overhead). How I understood your description is that you cache information about what user object types you have in the kernel. That costs you another check on the critical path. You argue that single method of invocation is a good thing--yes. We have that, it is called IPC. For all kernel objects (we have threads, AS, and memory) I don't see a benefit of a unified interface. That leads to IOCTL and that is a mess. If you want to use a generic interface (i.e. IPC) to _all_ kernel objects you can always place a protocol translation layer in between at almost no cost (threads and AS are manipulated very infrequently). This allows for optimizations you can't perform otherwise. > My first point is probably self-explanatory, so I will expand only on > the second. > > In L4, if a client wishes to perform an operation on a file, > the "name" > of the file must be passed as an argument to an IPC. The invocation is > something like: > > file_server->invoke(file-id, operation-id, ... other args ...) > > Because "file" is not a kernel-supported object, the protocol mandates > that the sender provide an additional argument in the IPC > invocation. In > the EROS philosophy, we would argue that these objects are therefore > "second class" and that this is bad for several reasons: > > 1. The invoker should not know the server identity. That should > be known only to the file object. > 2. It is difficult to transparently virtualize objects when their > invocation patterns are different. 1) Assume threads have zero costs. That means you can have one thread per object and the thread id is your identifier. 2) Assume you want to share a thread for multiple object invocations (and threads have costs > 0). The additional check you have to perform on _every_ object invocation (code for checking, table access, I and D-cache footprint etc) in EROS has probably a higher overhead than the additional parameter on the invocation which is untouched by the kernel. For concurrency (multiple worker threads) you can use LIPC in L4 so you can perform load distribution in user land. 3) Virtualizing objects is only a question of protocols. That is something _userland_ defines. So why should virtualization be difficult??? (I'm puzzled). Furthermore, how do you deal with situation where your object space is full? Is the object space local or global? We can dynamically extend and shrinl the object space (e.g. use a single bit if we have only 2 object types). > Next problem: > > The server must then run some function: > > get_permissions(sender-id, file-id) -> permissions > > to determine what operations are permitted. Note that if this > operation > is performed faithfully and correctly, it is impossible to emulate > correctly the behavior of the UNIX I_SENDFD socket operation without > many additional calls to a shared service -- the design of > the operation > makes descriptor transfer an inherently expensive operation. I would say that is a weak argument considering all the shortcomings of the POSIX API. Implementing fork within a distributed system is very expensive--so what? We know for more than 10 years that fork is broken. I will look into I_SENDFD into more detail and try to give you a satisfactory answer. > Descriptors, which *can* be used as a foundation for certain kinds of > security, suddenly become extremely inefficient because they cannot be > passed without consulting a third party. You can cache that information in user land after validation or use shared memory with the authentication server. That is what you basically do in the kernel. > The server-defined-bits portion cannot be examined by the > client. It is > provided to the server during invocation. The server can > interpret these > bits in any way desired: as an object id, as a facet id, as permission > bits, as some mix of these. > > The presence of these bits does not preclude invocation of the server > qua server; the server merely assigns to itself an arbitrarily chosen > value of "server-defined-bits" to name the server itself. So you provide an in-kernel cache for some identifiers (call it bits) which are unforgeable. How much of your register real estate do you give up for that? What when the size is exceeded? > Because these are architecturally insufficient to implement an > efficient, secure, object-based operating system. Hmm, actually that is a question of what you try to implement. What if you don't want an object-based OS? Do you incur a significant overhead with your model? I'm curious how a Linux kernel would perform on top of EROS--I could imagine that your security model has a measurable overhead. And then we have to start a discussion on generality of uKs. > Our experience has been that relying on such clients to specify the > intended operation is not robust. The flow of permissions in complex > programs is not well localized, and it is very easy to write a > subroutine designed for one purpose that does some mildly dangerous > thing and then call it (by programmer error) in the middle of some > sequence of code where care is required. > > Tying permissions to the object descriptor does not prevent the > programmer from passing the wrong descriptor, but it does help a great > deal in localizing the scope of programmer attention that is > required to resolve these problems. This sounds like you are suggesting kernel design based on bad programming habits. Are you willing to pay the overhead? We don't. - Volkmar

4 3

Comparing IPC and capability invocation
by Jonathan S. Shapiro 21 Dec '03

21 Dec '03

[I apologize in advance for both the length and the depth of this note.] One of the long-term design differences between L4 and EROS is something I think of as the "threads vs. objects" distinction. In L4, all invocations are IPC invocations performed on thread ids. In EROS, all invocations are capability invocations performed on capability indexes. In the current EROS implementation, the capability indexes are an offset into a per-process capability table. In my opinion, the original "name by thread-id" design in L3/L4 had two architectural issues: 1. It exposed the location of the target thread within the thread table. Because of the tight relationship between threads and tasks, this had the side effect of exposing potentially significant information about the internal structure of the recipient. It also made relocating a thread within the table challenging, because the thread's "address" was sitting in data space in every client, where one could not update it. My opinion was that the thread-id was effectively an absolute address, and that it should have been a virtual address that was decoded w.r.t. a sender-defined name space. 2. Because the thread id's and task ids were inter-related, there seemed to be a number of awkward restrictions on allocation of task structures. In particular, it was necessary to know in advance how many threads (max) were going to be required, and it was possible for fragmentation to prevent successful allocation even when the necessary number of thread entries was available. This seemed unnecessary. In addition, I thought it would be better if an address space could exist without any threads at all, and conversely if a thread could exist (though not execute) without any address space. From the EROS experience, I felt that non-process address spaces were useful. I'm not sure that threads without address spaces are useful, but I do believe that threads and address spaces are separable abstractions, and that it is good to keep them so. >From various conversations, I believe that the L4 team has addressed the second issue, and is considering a number of solutions to the first, most notably "thread address spaces". In this approach, the current thread id is replaced by an offset (or address) into the thread address space, and an application supplies this thread address instead of the thread id of the previous design. If I understand matters correctly, this idea has not yet been incorporated into the current L4 implementation but there seems to be agreement that someday it should be. I may have misunderstood, but I also believe that the power of two restriction on task allocation has been removed, and that any thread can now be associated with any task. As long as there is no operation allowing a sender to *read* the real thread id out of the thread address space, then the current plan for L4+thread-spaces would implement something very close to the future EROS design. There are two differences: 1. The current EROS design is currently expressed in terms of capability registers. We have decided that this should be replaced with a capability address space. Conceptually, this capability address space serves the same role in our architecture that the thread address space serves in Ln. 2. The elements indexed by this address space are capabilities in EROS, but thread-ids in L4. This is the heart of why I think of this as the "threads vs. objects" distinction. One way to think about this [the motivation will become clear in a moment] is that the L4 thread address space is actually a descriptor address space, but that all of the descriptors in this space are restricted to be thread descriptors. Since this appears to be the *only* remaining difference in this area of the Ln and EROS designs, I'ld like to make a case based on the EROS experience for why descriptors should be considered seriously in a future system. First, switching to descriptors should not significantly change IPC performance. A descriptor is probably a larger data structure than a thread id, but in both cases there is a load instruction at the end to place the target thread address into a register. This is true in both a thread-id design and a descriptor design. The difference would be only that the thread structure pointer might live at a different offset. Second -- and here I must draw for a moment from the EROS experience -- unifying all invocations behind a single descriptor abstraction has been incredibly useful in the EROS system. As with L4, we have a generalized invocation mechanism, but we can apply this mechanism to arbitrary objects. Introducing a generalized descriptor notion into the architecture does NOT necessarily imply a large increase in kernel size. When Leendert van Dorn and I were considering kernel design at IBM, we concluded that most of the resulting kernel descriptor types can be served by well-known user mode servers if desired. The decision about whether or not to put support in the kernel for these object types becomes purely an engineering decision. The EROS implementation chose to place these implementations in the kernel, and in one or two cases this is probably essential, but in general it is NOT necessary. The difference between a thread-id and a descriptor is that a descriptor takes the form (resource-type-code, resource-name, type-specific-data-word) where a resource-type-code is assigned for each kernel resource that is exported by means of a descriptor. Borrowing from EROS, the descriptor types that seem likely to be useful are: void -- descriptor that responds with "unknown" to all requests flexpage -- name of a flexpage thread -- a thread-id (interface to the process abstraction) object -- a particular object served by some thread In flexpages, the type-specific field holds permissions. In objects, it holds an object id. In threads, it might be unused. The EROS implementation also includes linked list pointers so that outstanding descriptors can be efficiently revoked when a resource is destroyed, but this is a detail of implementation -- other representations are possible. On revocation, outstanding descriptors become void, but we have sometimes thought that it would be better to mark change them from "type X descriptor" to "type INVALID X descriptor". This would facilitate debugging. An added word about the 'object' type may be useful, since it reflects a significant philosophical difference between L4 and EROS. In EROS, a client invokes an object. This object may be an entire server (a process) or it may be a particular object that is served by that server. In L4, the "particular object" case is customarily handled by passing an object id as an argument to the IPC operation. One problem with this is that the object id can be forged by the client. It is not entirely clear to me whether forged object ids are a serious problem in the absence of persistence, but my instinct is that they are *sometimes* a problem, and that including them is therefore desirable. The "IPC indirection" design proposed by Trent Jaeger et al. many years ago included a similar uninterpreted word. shap -- Jonathan S. Shapiro <shap(a)eros-os.org>

5 11

Re: Comparing IPC and capability invocation
by Rudy Koot 12 Dec '03

12 Dec '03

I've been following this discussion and I first want to say that I agree that threads should be virtual objects. The cuse of thread IDs on L4 now requires eiter the receiver to check if the sender had the rights to send to it or the use of IPC redirection. Both methodes make it easy for security holes to creep into the code and are (as you correctly pointed out) even slower than using virtual objects. And if the map, grant and unmap operations can be used on them they are even more flexible than the current implementaion. I'm however still doubting wherer EROS capabilities are necessary, because I believe the arguments you have given are entierly correct >In L4, if a client wishes to perform an operation on a file, the "name" >of the file must be passed as an argument to an IPC. The invocation is >something like: > > file_server->invoke(file-id, operation-id, ... other args ...) >In EROS, the corresponding invocation would be: > > file_capability->invoke(operation-id, ... other args ...) While this might be true at the lowest level, high level abstactions will geneally hide this fact from you, making this only an aestatic argument unless you can tell me why one of them is technically better/safer. And I think the examples you give here have been given in a form that is more favorable for de EROS case. The true inkovations would normally look more like this: L4: invoke(file_server_thread, file_id, operation_id, other_args) EROS: invoke(file_capability, operation_id, other_args) Again I want to stress that this is normally hidden by the high level language interface. Some interessting thing can also be done with alternative designs. For example the open call op the file_server creates a new thread that handles the calls to that file. The calls would now look like this: L4: invoke(file_thread, operation_id, other_args) EROS: invoke(file_capability, operation_id, other_args) Looks pretty similar doesn't it. The difference is now that in L4 the messages are send to a collection of threads while in EROS it is only one thread. -- Rudy Koot _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/

1 0

l4-hackers@os.inf.tu-dresden.de
by xaoveeyoyobb＠spammotel.com 12 Dec '03

12 Dec '03

1 0

Question on "mappings as cache"
by Jonathan S. Shapiro 11 Dec '03

11 Dec '03

I am trying to understand the implications of the "mapping is a cache" design argument. I suspect that this design can only be upheld if encapsulation is violated. First, however, I would like to understand the sequence of events in the following scenario: Consider a situation in which A maps some region to B B completes the receive operation, and therefore now has a copy of the mapping B is immediately preempted, before it can do any user-level book keeping about the mapping ... other stuff runs ... kernel runs out of mapping cache space, chooses to evict the mapping just received by B ... other stuff runs ... B attempts to reference the region that it believes should be mapped, and page faults. Can someone explain the process by which B is able to get the mapping reconstructed? shap

5 9

RE: Naive question about grant/map
by Volkmar Uhlig 11 Dec '03

11 Dec '03

> -----Original Message----- > From: Kevin Elphinstone > Sent: Wednesday, December 10, 2003 8:57 PM > To: 'Jonathan S. Shapiro' > Cc: 'L4 Hackers List' > Subject: RE: Naive question about grant/map > > Just a small, but important point relating to the statement below. > > The L4 mapping database is NOT strictly a cache, but it can be used to > implement cache-like behaviour which is usually what is done in most > systems. Kernel mappings are a dynamic subset of things defined at > user-level. However, in kernel mapping can be used to > indirectly define an address space or region of an address space > (if, for example, you what to avoid faults). I.e. it can equal > or be a superset of what is defined at user-level. However, doing > so requires carefully crafted and coordinated pager behaviour/protocol. > > You can term it a (large) cache with mechanisms to control > its population, but it is not exactly a "cache" in the terms usual > sense of the word. This also depends on your point of view. Your statement that the kernel mapping can be a superset of user-level pagers is wrong. The user-level pagers have full knowledge about the replacement policy (since it is implemented in user land via map and unmap) and therefore can rely on the fact that the kernel won't replace entries in the cache. If it would be a superset then the kernel would have to enter values itself. - Volkmar

2 1

Naive question about grant/map
by Jonathan S. Shapiro 11 Dec '03

11 Dec '03

I have a note about mappings and address spaces pending, but before I send it I want to ask a naive question about the map operations: Consider a sequence of operations in which A maps to B B maps same stuff to C. Is there some variant of the 'map' operation in which B does NOT retain the ability to revoke C's mapping? That is, in which the resulting mapping dependency hierarchy is A / \ B C instead of A | B | C That is, is there a way for a sender to give a receiver rights on data that are co-equal in all respects with those of the sender? If not, is it important? If such a "coequal map" operation existed, how often would it be used in contrast to the current map operation? shap -- Jonathan S. Shapiro <shap(a)eros-os.org>

8 13

systemclock
by Sebastian Bogan 10 Dec '03

10 Dec '03

Hey, I am using the latest L4Ka::Hazelnut. I was wondering how a usertask can access the systemclock. In X.2 they talk about a systemcall `systemclock' but it seems, that this call was not yet implemented.? Thanks for advise. Ciao Sebastian Bogan

2 1

The code size of Fiasco µ-kernel
by jwy002 08 Dec '03

08 Dec '03

Hi, Can anyone give me a rough figure about how much memory space is needed by L4 u-kernel? Thanks. Joseph

3 3

Memory mapping
by Jonathan S. Shapiro 08 Dec '03

08 Dec '03

One of the essential differences between EROS and L4 is their handling of mapping state. In light of Hermann's note: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2003/001559.html I am beginning to believe that the difference in mapping architectures may be the only really basic difference. It affects how we think about caching of mapping state, how we think about memory management algorithms, and so forth. Before I start, I want to say "thank you" to Volkmar. In trying to understand the L4 model, I have gone through a progression of confusions. It is possible that I am still confused. The key clarification was Volkmar's comment that the current L4 map operation proceeds entirely on the native page tables in the x86 implementations. I currently believe that *neither* the L4 mapping system nor the EROS mapping system is adequate today. I have been thinking lately about how to find a happy middle ground, and I provisionally believe that I may have one. That will be the subject of my next note. So: The key differences between the L4 mapping state and the EROS-NG (next generation) mapping state may be described as follows: + In L4, the only important state is the state recorded in the mapping database. This state is a cache, and applications are required to be able to reconstruct their own mapping state on demand. Mappings are not named by any sort of name (local or global) that can be directly referenced by any application. Because they cannot be named, mappings are not first class objects -- there is no contract with any application about the kernel's logical mapping structure. Page fault handling is done at the granularity of a 'task'. + In EROS-NG, address spaces are expressed as guarded page tables (GPTs), and every GPT is named by a capability. GPTs are therefore first-class objects exported by the kernel. The kernel can "page" these objects in the same way that it can "page" data pages, but it is not free to discard them. Page fault handlers can be injected at any arbitrary GPT. There seem to be advantages and disadvantages to each design. 1. Cost of mapping: I believe the the correct way to measure the cost of a map operation is to include all of the costs necessary to actually get a valid PTE into the recipient address space. * L4 Map The dominant cost in the L4 map operation is the cost to build the necessary mapping DB entries in the kernel. PTEs are copied aggressively, so there are usually no further hardware page faults needed to load them when the recipient starts running. In addition to the kernel-level map operation, the recipient task must record the incoming mapping in some per-task database. This database essentially duplicates the state in the kernel, though my guess is that it can be accomplished via a region-based recording scheme in the usual cases (that is: I record that X bytes from File Y got mapped starting at address A, and that faults in this region should be recovered by making a request to thread-id T). It is not clear to me what the practical overhead of this additional tracking is. Unless something has changed in a way that I have failed to understand, L4 does not provide a means to share page tables across more than one task. * EROS-NG map (capability transfer) The dominant cost in the EROS-NG design is the cost of the page faults. PTEs are NOT transferred eagerly, and the recipient takes a fast path per-page fault to validate each mapping when it is first encountered. These mapping validation faults can be "batched" for performance, but the current EROS implementation does not do so, and there does not appear to be any compelling performance-motivated reason to *want* to do so. The kernel uses a variety of tricks to make these traversals more efficient on architectures that implement hierarchical page tables. In the current EROS system, there are several steps required on the part of both sender and receiver to extract the relevant capability for transmission and to insert it into the desired location in the recipient space. In EROS-NG these steps are accomplished in the kernel, though they may result in what I might call "GPT faults" -- I'll try to explain this in my next mail. For some architectures, it is an important point that the EROS strategy guarantees page table sharing whenever doing so is (a) possible and (b) correct -- even across threads that do not share an address space. In our experience, page table sharing is very important to overall system performance. This sort of sharing is especially important to provide efficient support for shared libraries. 2. Cost of Unmap: The costs of unmap in the two systems seem comparable if the implementation is done with care. Because EROS-NG provides explicit names for the GPTs, and because it is possible to build "alias" GPTs, the EROS unmap operation can be used more selectively than the L4 unmap operation. This may not be a critical issue. 3. Encapsulation If I understand matters correctly, an L4 page fault is always reported first to the client's per-task page fault handler. In EROS, page fault handlers can be associated with arbitrary regions of the address space, and faults delivered to these handlers are usually invisible to the client (except for latency). Mach, just for comparison, does per-region page fault handlers. They are not structured like those of EROS, but like EROS they allow specification of address fault handlers on a region by region basis. When I first encountered KeyKOS, I didn't see why this distinction mattered. Here is an example that may help clarify whether or not this distinction is important: Imagine that client C maps a file F into the address space of C. Portions of the file data may not be in memory, and may need to be demand paged. Note that C cannot have enough information to accomplish this demand paging action. At *best*, C has enough information to ask the file server to provide the missing mapping. Because C is not in a position to actually solve the problem, I would argue that the kernel has misdirected the fault. The L4 design appears to require more IPC steps than the corresponding EROS design, because it requires an extra IPC operation. >From an abstraction perspective, there is a second objection: the demand paging of this object is really none of C's business, but C is given full knowledge of all of the faults. This is an encapsulation failure. In fact, the design places a burden of mapping work on C that appears to me to be unnecessary. The one argument I see that might make this design desirable is the argument that the L4 kernel is simplified as a result. While I certainly believe that this is true, I think that the absence of first-class memory objects is a potential weakness. 4. Space The EROS-NG design is more space intensive in the kernel, because the kernel must maintain two representations of the mapping structure and a correlation structure: 1. The GPTs 2. The page tables 3. The depend table (for dependency tracking) The hardware page tables and the depend tables can be discarded at any time, and the GPTs are pageable. I do not believe that requiring more kernel space is inherently bad -- the issue is the amount of total pageable space at user and kernel levels combined. We have no evidence from the EROS work that total kernel virtual addressable space is at risk from this particular increase. The EROS kernel translation strategy is more complex than the corresponding L4 strategy. I do not believe that this is necessarily bad. More precisely, I believe that *all* of the complexities of mapping need to be examined together; not just the complexities that are incurred in the kernel. It is reasonable and desirable to push function out of the kernel when the cost of doing so is not excessive. Random Comments: It appears to me that there are peculiar boundary conditions implicit in the L4 design: if the very last page of a process is paged out, I am not sure how its pager thread runs, because I do not understand what memory that pager thread references in order to initiate instructions or store temporary data. I suspect that the solution is that the pager thread in turn specifies a pager thread (which I will call the meta-pager), and the meta-pager arranges to page enough state back in that the pager thread can make progress. Probably this all seems perfectly obvious to people who are familiar with L4. I find it confusing that every process must have two threads or must delegate mapping management to a third-party task. shap

2 1

Question about map operation
by Jonathan S. Shapiro 06 Dec '03

06 Dec '03

Believe it or not, I'm converging, but I'm trying to do it respectfully, which means asking an unreasonable number of stupid questions at high speed. :-) Now that I understand the shape of GPTs, I would like to understand the *mechanism* of the map operation. In particular, I would like to understand how the book-keeping mechanism works. It may be that this has been written up, and that I just haven't found it -- appearances notwithstanding, you guys collectively write faster than I do alone :-) Bootstrap conditions: 1. When a new, virgin, never-before-used task is created, can it have a completely empty address space, or is an initial flexpage required as an argument to the task-create operation? I'm trying to learn whether a null address space pointer is ever a conceptually valid thing for a task to have. Map operation: 2. Suppose a sender maps a single page to a recipient task, and the corresponding recipient address was previously undefined. What data structures get constructed in the recipient's GPT? I am *guessing* that the answer is: the recipient GPT tree is expanded by inserting GPT nodes until a slot can be contrived into which *something* can be placed that reflects the existence of the new mapping. I would like to know what the *something* is. In particular, is it a GPT whose type is 'alias'? 3. In order to support the unmap operation, some book-keeping data structure is needed in which all of the derived mappings can be discovered. Can someone describe for the x86 what book-keeping structures are created at the time of the "map", and how they are used at the time of the "unmap"? I think this may be the MapDB that someone mentioned earlier. I've had a hard time getting a clear understanding of that. I ask about x86 only because it is the machine that is most current in my mind. Also, please note that I am *not* trying to ask how the hardware addressing structure gets built -- I can think of several ways to handle that. Thank you! shap

2 2

Question about L4 address spaces
by Jonathan S. Shapiro 05 Dec '03

05 Dec '03

Before sending out anything on the subject of address spaces, I've been going through everything I could find on how L4 handles them. I now (finally) understand guarded page tables, and it is *staggering* how similar these are to EROS nodes -- something that I had assumed must not be true because of the user-layer map/grant/unmap API. Regrettably, I was in a very bad state when I first read this work years ago, and I simply didn't understand it at the time. For those unfamiliar with EROS, the way to think about EROS nodes is that they are guarded page tables whose size is fixed at 32 entries, and whose guard value is defined as: 0000...000xxxxxxxx where the number of x's is determined by the size of the subtree described. If the maximum number of bytes in the described subtree is 2^k, then there will be log2(2^k) == k don't care bits in the guard value. EROS chose to keep all nodes (GPTs) the same size, though Norm Hardy and recently discussed changing this. The main reason for keeping them the same size has to do with paging them -- it is convenient for all pageable objects to be of uniform size. What Norm and I recently noticed was that this was a restriction on representation size, not on the logical data structure size -- this last point will make more sense in a moment. Note that the EROS guard values are significantly less flexible than those of L4 -- a problem that I had been looking for a way to fix. The fact that the guard value is restricted to be all zero's means that the EROS address space tree favors compression of leftmost legs in the mapping tree. This is useful for code and data regions, but useless for stack regions and not as helpful as it could be for other sparsely allocated regions. I am not convinced that the EROS mapping structures have any good place to insert a generalized guard value; I need to think about this carefully. The EROS wrapper node serves double duty, taking on both the role of the "alias" GPT type and also something very similar to the "call-on-reference" GPT type. EROS wrappers provide "call-on-exception" rather than "call-on-reference". The call-on-exception node translates no bits, but contains a pointer to a contained GPT that *may* translate bits. This allows a partially populated space to behave as a normal space in those regions where it is defined, but fall back to a process where the underlying space is NOT defined. A similar effect can be achieved in L4 by expanding a call-on-reference node recursively as subregions are populated, but this is not exactly the same -- there is a hierarchy of exception types (invalid -> read-only -> read-write), and one would like to be able to invoke the exception handler for each. My provisional belief is that the call-on-exception design is strictly more general, but that the conceptual difference is quite minor. So with all of the above being said, the *interesting* difference between L4 address spaces and EROS address spaces may be reduced to naming and implementation details. Which brings me to yet another question (forthcoming). shap

1 0

Re: Naive question about grant/map
by Jonathan S. Shapiro 05 Dec '03

05 Dec '03

On Fri, 2003-12-05 at 09:52, Marcus Völp wrote: > Jonathan wrote: > >Note that "B can ask A to map to C" may not be possible -- B may not > >have any permission to perform an IPC to A. For example, A may be a > >fault handler that can be accessed by B only for page faults, but not > >directly via arbitrary IPCs -- the reason for such a restriction would > >be to prevent B from sending hostile messages to the fault handler. > > > > > > Faults are just messages, so to get the page from A as a result of a > page-fault, the fault has to be send to A, either directly by B or by > some intermediates such as a region mapper. So this line could as well > be used to demand the mapping to be established to C. The only way when > this does not work is when B awaits a mapping from anyone and A by > chance sends this mapping. This however is a very strange situation, > isn't it? > > By the way, we are now discussing offline the mailing list. Jean also > told me that your discussion with him went of the list at some point... My apologies -- the EROS lists munge reply-to, and I'm having to get used to saying "reply to all" again. I may have unintentionally tripped over an architecture difference between EROS and L4. In case it is revealing, let me explain it. In EROS, a memory region has a designated fault handler. This is not exactly the same as L4 tasks. Rather, imagine that each entry in the L4 GPT could optionally specify a fault handler (a thread) to handle that subspace. Because EROS has this arrangement, it is possible that an address space will hold a fault handler capability that the client application does NOT hold. In this case, the only fault messages that will arrive at the fault handler are those initiated by the kernel in response to load and store instructions. I do not understand adequately how memory fault handling is structured in L4, but if thread descriptors are ever virtualized I suspect that L4 will have the same possibility. shap

1 0

Second naive question about map operation
by Jonathan S. Shapiro 05 Dec '03

05 Dec '03

A second naive question. Imagine that thread A performs separate map operations to each of B and C (maps of the same thing). This results in a dependency relationship of the form: A / \ B C Given that these operations have happened, is there a way for A to revoke the mapping held by B without also revoking the mapping held by C? Does it matter? -- Jonathan S. Shapiro <shap(a)eros-os.org>

3 3

Unifying EROS and L4
by Jonathan S. Shapiro 04 Dec '03

04 Dec '03

In preparation for the upcoming gathering in Dresden, I want to start some discussion about opportunities for unifying the L4 and EROS kernels. We have made some recent decisions in the EROS project that create a MUCH higher likelihood of success in this discussion. Similarly, the L4 team has been making progress on things that are drawing the two systems closer. Since this is a public mailing list, and since many of the participants have strong and well-motivated architectural sensibilities, I feel compelled to say: I am *not* interested in establishing which system is "better." I think that both systems have some very strong qualities, and I think that they are closer in spirit than matters at first appear. I also think that each system has weaknesses, and I am interested to figure out whether there may exist a hybrid architecture that combines the advantages of both, and might allow us to bring the two communities together so that we can make more effective progress. Let me also say at the start that I have *not* been lurking on the l4-hackers list, and that some of the issues I raise may already be "solved", either in the current implementation or in the sense that there is a commonly understood forthcoming design. To facilitate properly threaded discussions, I'll be dividing my comments into different architectural categories and sending them out under distinct subject lines. Regards, shap -- Jonathan S. Shapiro <shap(a)eros-os.org>

1 1

microkernel and realtime
by Yu Neil 24 Nov '03

24 Nov '03

hello: Recently, I consider implementation heritical scheduler on top of the l4 microkernel, But we meet a problem, the Pistachio handled the interrupt in microkernel internal, In that time, I remember a project in TU-Dresden is build on top of microkernel, But it`s implementation in the old l4 interface, just like the Hazelnut that not handled the interrupt (?), The suitation is some microkernel abstract the interrupt and some microkernel not abstract the interrupt. Can we implementation a real time soft mechanism with interrupt abstracted microkernel, the real time ipc, feature as: interrupt generated then a ipc send to handler and switch to the handler at once Neil _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

3 2

Various L4-related questions...
by Michael Engel 17 Nov '03

17 Nov '03

Hi, it's quite some time since I last had a look at L4 and a lot seems to have happened since then. As I'm planning to use a L4-derived microkernel as basis for a research project here at Marburg University, I have some questions for the experts... The currently maintained L4-compatible microkernels seem to be Fiasco (Dresden) and L4KA::Hazelnut/Pistachio (Karlsruhe). Is there a document describing the differences/compatibility between the various versions, probably comparing these implementations to the original L4 kernel? The platform for my project will probably be a AMD "Hammer"-based system (e.g. Athlon 64 or Opteron). Is there already work underway to run Fiasco or L4KA in 64-bit mode on the x86-64 CPUs? If not, I'm thinking about starting an effort to port one of the kernels (based on the x86-32 version). Which do you think would be most appropriate? Btw., the squirrel on the L4KA web pages is quite cute ;-) - is there a high-res bitmap or vector graphics version of the logo available? My last question concerns L4Linux. The most recent version seems to be based on kernel 2.2.25. Are there any plans to adapt a more recent Linux kernel version, like 2.4 or the upcoming 2.6, as a L4 personality? (I'm aware that this might involve a lot of work...) Best regards, Michael -- Dipl.-Ing. Michael Engel - mengel(a)informatik.uni-marburg.de Philipps-Universit=E4t Marburg - FB Mathematik und Informatik Hans-Meerwein-Str. - 35032 Marburg Tel. 06421 / 28 21562 - Fax: 06421 / 28 21573

4 3

Fiasco 1.1 microkernel released
by Udo A. Steinberg 11 Nov '03

11 Nov '03

Hello L4 hackers, The Fiasco Team is pleased to announce version 1.1 of the Fiasco L4 microkernel developed at the University of Technology, Dresden and released under the GNU General Public License (GPL). This Fiasco release is mostly a bugfix release. Among the new features added in version 1.1 is support for the ARM processor architecture, the integration of the powerful Fiasco kernel debugger (JDB) into the Fiasco-UX usermode kernel and a completely revised "tagged TLB" emulation (also known as small address spaces). For a more verbose list of changes since the last release see the CHANGES file. The Fiasco microkernel currently supports the stable version V.2 and the experimental version X.0 of the L4 interface specification and runs on x86 (i486 and above) and ARM SA1110 CPUs. The included Fiasco-UX port runs on any x86-based Linux system as a normal usermode application. For further information please visit the Fiasco homepage at: http://os.inf.tu-dresden.de/fiasco/ Happy hacking, The Fiasco Team

1 0

RE: l4-ka, c++!
by M. Edward Borasky 08 Nov '03

08 Nov '03

Thanks!! I'm just getting into this L4 / Hurd game. My main concern isn't efficiency -- I leave the speed issues to the folks who give us a 2X clock frequency boost every 18 months. :) My concerns are correctness and stability of the OS, and various project management issues like predictability and stability of dates, interfaces and specifications, production of accurate and usable documentation, etc. I'm by no stretch of the imagination a competent C++ programmer; I can just barely read C++ once the object-oriented features show up. In my trolling about, I discovered that the Fiasco folks have put some effort into "correctness proofs" of Fiasco. See the Vfiasco site http://os.inf.tu-dresden.de/vfiasco/ How difficult would it be to shift this effort from Fiasco to Pistachio? How difficult would it be to port DROPS and friends http://os.inf.tu-dresden.de/drops/ from Fiasco to Pistachio? I'm interested in both tracks -- a real-time operating system and a general-purpose Linux-like desktop and server system. "One OS to rule them all ..." :) -- M. Edward (Ed) Borasky mailto:znmeb@borasky-research.net http://www.borasky-research.net "Suppose that tonight, while you sleep, a miracle happens - you wake up tomorrow with what you have longed for! How will you discover that a miracle happened? How will your loved ones? What will be different? What will you notice? What do you need to explode into tomorrow with grace, power, love, passion and confidence?" -- L. Michael Hall, PhD

1 0

some newbie questions
by cyberspas＠narod.ru 05 Nov '03

05 Nov '03

Hello l4-hackers, I run my small program as root task on top of Pistachio 0.3 microkernel and receive some errors when it run. All works fine, but when in KDB i try to use change verbose level of sigma0 once and again (about 5-6 times) I receive Assertion: Assertion !tcb->queue_state.is_set(queue_state_t::ready) failed in file /home/tosha/pistachio-0.3/kernel/include/api/v4/schedule.h, line 296 (fn=f010099b2) Can you explain me where is the problem ? Code: #include <l4io.h> #include <l4/kip.h> #include <l4/ipc.h> #include <l4/message.h> #include <l4/kdebug.h> #include <l4/thread.h> int main (void) { printf("Myself: %x\n", L4_Myself().raw); L4_Msg_t msg; L4_ThreadId_t tid; tid = L4_Pager(); L4_MsgClear(&msg); L4_MsgAppendWord(&msg, 1); L4_MsgAppendWord(&msg, 9); L4_Set_Label(&msg.tag, -1001<<4); L4_MsgLoad(&msg); L4_Send(tid); printf("aaa\n"); L4_MsgClear(&msg); L4_MsgAppendWord(&msg, 1); L4_MsgAppendWord(&msg, 9); L4_Set_Label(&msg.tag, -1001<<4); L4_MsgLoad(&msg); L4_Send(tid); while(true) { printf("root\n"); L4_KDB_Enter("enter kdb"); } } -- Best regards, Anton mailto:cyberspas@narod.ru

1 0

Re: AW: L4/Linux communciation with another L4 thread
by Dominik Gummel 17 Oct '03

17 Oct '03

Hi, > I am working on the Perseus (www.perseus-os.org) project > and we are currently using an l4ka kernel. At the moment, we still use L4 V2. Greets, Dominik -- Universität des Saarlandes Department for Computer Science, Security and Cryptography Dominik Gummel email: bofh(a)krypt.cs.uni-sb.de Building 45, Room 536 Im Stadtwald,D-66123 Saarbrücken Tel.: +49(681)302-5608 Fax.: +49(681)302 5636 public key http://www-krypt.cs.uni-sb.de/~bofh Fingerprint 8BED E39C 711C 3ECA B35F E5E7 846D 6661 C091 51AE

1 0

L4/Linux communciation with another L4 thread
by perseus 16 Oct '03

16 Oct '03

@postmaster: Sorry for any inconvenience. had problems with my email application Hi, I am quite new to L4 and I did succeed in writing a server task for L4 and to call this with another L4 thread/program. (Did start them by modifying menu.lst). But I did not find out how I could communicate with an L4/Linux program and another L4 server. I want to send/receive data. Is there any code around that copes with this feature? Thanks, Gerhard

2 2

L4/Linux communication with another L4 Thread
by GLeibrock 15 Oct '03

15 Oct '03

Hi, I am quite new to L4 and I did succeed in writing a server task for L4 and to call this with another L4 thread/program. (Did start them by modifying menu.lst). But I did not find out how I could communicate with an L4/Linux program and another L4 server. I want to send/receive data. Is there any code around that copes with this feature? Thanks, Gerhard

1 0

L4 & Ada
by Frederic BOYER 03 Oct '03

03 Oct '03

Hello I'm plan with a friend (Antoine) to port the L4lib from C to Ada. So, it will be possible to write L4 server in Ada. I'd like to know if someone have already try to do a such thing, and I'd like advices from L4 guru to begin the work. Thanks, Frédéric. "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Crédit Agricole Indosuez Cheuvreux except where provided for in a written agreement. Crédit Agricole Indosuez Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Crédit Agricole Indosuez Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein."

1 0

about L4 tables
by Yu Neil 29 Sep '03

29 Sep '03

hello: after l4 booted, it will allocate some tables in address, How many memory it will ocuppied ? Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

Multiple Test Environments
by David Denny 21 Sep '03

21 Sep '03

Hello L4 There seemed to be a sentiment that your group might appreciate having the Fiasco installation process tested under a variety of Linux distributions. I've had to swap the machine I'd originally acquired for this project, because of video issues with Fiasco (onboard card, Compaq mobo, say no more), so I have a bit more disk space and with careful use of the server I can probably compile/install for between 4 and 6 distributions. Those I have in mind are Debian (as a basic sync point with yourselves). SuSE as an RPM distro, Slackware because it's different, and the two DIY distros LFS and Gentoo. What I envisage is coming back to yourselves _only_ if I have Debian issues, and for the other distros I'm happy to hack my way through and send you back the completed "Expedition Log" for each of them. That is, if you'd like to have something as a resource for other external users to use. I would not expect to ask for help outside Debian. My time is limited so I would tend to go for a major hacking event, from time to time, rather than keeping up with things as they happen At The Centre as it were. I run other free *nixes but my feeling is that at present, as an evaluation envelope, Linux is sufficient for your needs. Looking forward to this, rather

1 0

RE: build error
by "Wen, Jun (溫軍 IAC-N)" 11 Sep '03

11 Sep '03

Hi, thanks,now I am using i386-elf-gcc,but also has some error. would you please give a advise which compiler and which enviroment could compile them pass? i am using fiasco-1.0.tar.gz and fiasco-1.0-oskit.tar.gz BRS john -----Original Message----- From: Volkmar Uhlig [mailto:volkmar@ira.uka.de] Sent: Wednesday, September 10, 2003 11:59 AM To: Wen, Jun (? ? IAC-N) Cc: l4-hackers(a)os.inf.tu-dresden.de Subject: RE: build error Using the native cygwin compiler will quite likely make you pulling your hair out. Try building a cross compiler for linux and elf and use that instead. The PE standard the cygwin gcc spits out conflicts with many assumptions in asm code and linker files, such as naming conventions of sections, symbols, etc. - Volkmar

1 0

RE: build error
by Volkmar Uhlig 10 Sep '03

10 Sep '03

Using the native cygwin compiler will quite likely make you pulling your hair out. Try building a cross compiler for linux and elf and use that instead. The PE standard the cygwin gcc spits out conflicts with many assumptions in asm code and linker files, such as naming conventions of sections, symbols, etc. - Volkmar

1 0

RE: build error
by "Wen, Jun (溫軍 IAC-N)" 10 Sep '03

10 Sep '03

Hi thanks for reply quickly.follow advise it shows below. BRS john make -I../src -f ../src/Makefile \ srcdir=../src "all" Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs make[1]: Entering directory `/cygdrive/f/fiasco-1.0/l4/kernel/fiasco/build' ... Making context-ia32-ux.o g++ -v -c -MD -I../src/types/ia32 -I../src/types -I../src/drivers/ia32 -I../src/ drivers -I../src/kern/ia32 -I../src/kern/shared -I../src/kern -I../src/boot -I.. /src/lib/libk/ia32 -I../src/lib/libk -I../src/lib/kern/include -I../src/lib/amm -I../src/lib/lmm -I../src/lib/gzip -I../src/lib/disasm -I../src/lib/minilibc/ia3 2/include -I../src/lib/minilibc/include -I. -Iauto -fno-rtti -fno-exceptions - march=i586 -fomit-frame-pointer -mpreferred-stack-boundary=2 -fno-defer-pop -fr eg-struct-return -g -Wall -W -finline-limit=2000 -O3 auto/context-ia32-ux. cc - o context-ia32-ux.o Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable-languages=c,c++,f77,ja va --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --with out-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-ve rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc -cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecd ir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) /usr/lib/gcc-lib/i686-pc-cygwin/3.2/cc1plus.exe -v -I../src/types/ia32 -I.. /src /types -I../src/drivers/ia32 -I../src/drivers -I../src/kern/ia32 -I../src/kern/s hared -I../src/kern -I../src/boot -I../src/lib/libk/ia32 -I../src/lib/libk -I../ src/lib/kern/include -I../src/lib/amm -I../src/lib/lmm -I../src/lib/gzip -I../sr c/lib/disasm -I../src/lib/minilibc/ia32/include -I../src/lib/minilibc/include -I . -Iauto -MD context-ia32-ux.d -MQ context-ia32-ux.o -D__GNUC__=3 -D__GNUC_MINOR __=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_X86_=1 -D_X86_=1 -Asyste m=winnt -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__ i386 -D__i386__ -D__i586 -D__i586__ -D__pentium -D__pentium__ -D__tune_i586__ -D __tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__fastcall=__attribu te__((__fastcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_stdcall=__attribute __((__stdcall__)) -D_fastcall=__attribute__((__fastcall__)) -D_cdecl=__attribute __((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D__i386 -D__CYGWI N32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -isystem /usr/lib/gcc-lib/i686-pc- cygwin/3.2/../../../../include/w32api -isystem /usr/lib/gcc-lib/i686-pc-cygwin/3 .2/../../../../i686-pc-cygwin/lib/../../include/w32api auto/context-ia32-ux. cc - D__GNUG__=3 -D__DEPRECATED -quiet -dumpbase context-ia32-ux.cc -march=i586 -mpre ferred-stack-boundary=2 -g -O3 -Wall -W -version -fno-rtti -fno-exceptions -fomi t-frame-pointer -fno-defer-pop -freg-struct-return -finline-limit=2000 -o /cygdr ive/c/DOCUME~1/INC970~1/LOCALS~1/Temp/ccNnjfaX.s GNU CPP version 3.2 20020927 (prerelease) (cpplib) (80386, BSD syntax) GNU C++ version 3.2 20020927 (prerelease) (i686-pc-cygwin) compiled by GNU C version 3.2 20020927 (prerelease). ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/i686-pc-cygwin/include" ignoring duplicate directory "/usr/i686-pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: ../src/types/ia32 ../src/types ../src/drivers/ia32 ../src/drivers ../src/kern/ia32 ../src/kern/shared ../src/kern ../src/boot ../src/lib/libk/ia32 ../src/lib/libk ../src/lib/kern/include ../src/lib/amm ../src/lib/lmm ../src/lib/gzip ../src/lib/disasm ../src/lib/minilibc/ia32/include ../src/lib/minilibc/include . auto /usr/include/w32api /usr/include/c++/3.2 /usr/include/c++/3.2/i686-pc-cygwin /usr/include/c++/3.2/backward /usr/lib/gcc-lib/i686-pc-cygwin/3.2/include /usr/include End of search list. /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/as.exe --tra ditional-format -o context-ia32-ux.o /cygdrive/c/DOCUME~1/INC970~1/LOCALS~1/Temp /ccNnjfaX.s /cygdrive/c/DOCUME~1/INC970~1/LOCALS~1/Temp/ccNnjfaX.s: Assembler messages: /cygdrive/c/DOCUME~1/INC970~1/LOCALS~1/Temp/ccNnjfaX.s:826: Error: unknown pseud o-op: `.previous' make[1]: *** [context-ia32-ux.o] Error 1 make[1]: Leaving directory `/cygdrive/f/fiasco-1.0/l4/kernel/fiasco/build' make: *** [all] Error 2 -----Original Message----- From: Udo A. Steinberg [mailto:us15@os.inf.tu-dresden.de] Sent: Wednesday, September 10, 2003 9:24 AM To: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: build error _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

1 0

build error
by "Wen, Jun (溫軍 IAC-N)" 10 Sep '03

10 Sep '03

Hi, i am new to L4 and trying to build l4 using cygwin.but get some error like this in \fiasco-1.0\l4\kernel\fiasco\build just make ---------------------------------------------------------------------------- ----------------------- g++ -c -MD -I../src/types/ia32 -I../src/types -I../src/drivers/ia32 -I../src/dri vers -I../src/kern/ia32 -I../src/kern/shared -I../src/kern -I../src/boot -I../sr c/lib/libk/ia32 -I../src/lib/libk -I../src/lib/kern/include -I../src/lib/amm -I. ./src/lib/lmm -I../src/lib/gzip -I../src/lib/disasm -I../src/lib/minilibc/ia32/i nclude -I../src/lib/minilibc/include -I. -Iauto -fno-rtti -fno-exceptions -mar ch=i586 -fomit-frame-pointer -mpreferred-stack-boundary=2 -fno-defer-pop -freg- struct-return -g -Wall -W -finline-limit=2000 -O3 auto/context-ia32-ux.cc -o c ontext-ia32-ux.o /cygdrive/c/DOCUME~1/INC970~1/LOCALS~1/Temp/ccjaRJqc.s: Assembler messages: /cygdrive/c/DOCUME~1/INC970~1/LOCALS~1/Temp/ccjaRJqc.s:826: Error: unknown pseud o-op: `.previous' ---------------------------------------------------------------------------- ---------------------------- any suggestion will be appreciated! BRS john

2 1

Re: L4Linux boot stop "param_word bits 16-19 must be 0. Fix yourbindings!"
by Udo A. Steinberg 07 Sep '03

07 Sep '03

On Fri, 05 Sep 2003 20:45:53 +0100 David Denny (DD) wrote: DD> I've now got myself a sensible environment and I know which compiler is DD> which. I have jdb but not kdb. I have no info to help me debug the DD> "fix my bindings" message that I can interpret. KDB has been superseded by JDB. JDB is in fact the Fiasco kernel debugger. When entering the kernel debugger, you should get a line similar to this: ---------------------------------------------------ESP:201807a8 EIP:00006526 (6.00) jdb: 6.00 in this case is the thread that was active, when the debugger was entered (thread 0 of task 6). When the "fix your bindings" message appears, then note the task number (number before the dot). Compare it to the task numbers that "rmgr" or "loader" report when starting tasks, i.e. RMGR: loading "pingpong-ux" from 01d37000-01d6f72d to [ 00800000-0080f1c3 00810000-00960580 ] task #0x06 at entry 00800000 via trampoline page code 00070150 ^^^^^^^^^^ Task 6 is pingpong-ux or loader | vmlinuz.l4env,#f: Continue at l4env_init (00013350, libloader.s.so) ^^^^^^^^^^^^^^^^ Task 0x0f is L4Linux And voila, you'll find the offending program that needs fixing. DD> Is it possible that it's DD> the linux22 that needs checking out again, as this is what is loading just DD> prior to the message? Could well be. Only the task number will tell you for sure. Remote-CVS has been updated recently (Friday, Sep 5), so all the fixed bindings should have propagated to the wide world. DD> Furthermore, have you instructions on cvs checkout for packages? I've DD> only been to the website and my cvs's so far have been for the package DD> groups like linux22, hello, oskit, etc. You don't need to re-checkout packages. A simple "cvs update -dP" in any of your checked out directories will bring it up-to-date. Of course you still need to recompile the relevant packages afterwards. -Udo.

1 0

New cli/sti semantics in Fiasco 1.0?
by Jacob Gorm Hansen 30 Aug '03

30 Aug '03

hi, as far as I recall, Fiasco used to re-enable interrupts upon returning from a syscall, even if they had been disabled before the syscall. Some of my old code (my patched version of L4Linux22 which I am using with nomadbios) seems to have relied on this behaviour and now fails with a "page fault in cli mode" on the first intruction after an IPC-operation. Am I correct that the behaviour has been changed like this, or do I just have to configure my Fiasco differently? The old Fiasco I am using is from CVS about a year ago. thanks, Jacob

1 1

l4/pkg/con etc
by David Denny 30 Aug '03

30 Aug '03

Hello Hackers. Having got to the stage of compiling successfully my second (debian) hello+fiasco+glinux set, I'm now looking at cool next step (read: "easy wins for the temporally challenged"). UX and CON seem to be my candidates. OK, UX looks more like the world I'm used to, so I won't ask about that yet. But I /do/ have a Q. about the drops con, which has wider learning implications, so a few hints here won't go amiss. My guess is that to yield up a con binary, I cd to l4/pkg/con, "make", and /no/ that isn't it because it falls over... my predecessor instructions were per website, CVSco, compile hello and fiasco using gcc3.2, compile linux22 using gcc2.95. so: how do I compile "con" and other packages, please? (or: a generalised rule to cover this) ;-) TIA David D

2 1

L4Linux boot stop "param_word bits 16-19 must be 0. Fix your bindings!"
by David Denny 28 Aug '03

28 Aug '03

Hello Hackers booting l4linux stops with: KDB: thread_schedule: param_word bits 16-19 must be 0. Fix your bindings! My grub menu contains: +-------------------------------------------------------------------[0]---+ | 0: kernel (hd0,2)/denny/Dresden/rmgr -sigma0 | | 1: modaddr 0x02000000 | | 2: module (hd0,2)/denny/Dresden/main -nokdb -nowait -comspeed 9600 -com| | 3: module (hd0,2)/denny/Dresden/sigma0 | | 4: module (hd0,2)/denny/Dresden/glinux root=/dev/hda3 | | 5: module (hd0,2)/denny/Dresden/hello umm, pasting from the remote serial console.. line 2 ends in "-comport 1" OK let's reboot the big system & paste the whole thing. BTW your hackked grub is now sitting in the mbr of (hd0) AND it WORKS ! 8-) title failsafe chavin:/boot/grub # less menu.lst # Modified by YaST2. Last modification on Tue Aug 26 06:06:59 2003 color white/blue black/light-gray # default 0 # timeout 8 serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 #terminal --timeout=10 serial console terminal serial console title SuSE Linux 8.2 Kernel 2.4.20 kernel (hd0,2)/boot/vmlinuz root=/dev/hda3 vga=0x31a splash=silent showopts initrd (hd0,2)/boot/initrd title (Remote) SuSE Linux 8.2 Kernel 2.4.20 kernel (hd0,2)/boot/vmlinuz root=/dev/hda3 console=tty0 console=ttyS0,9600n8 initrd (hd0,2)/boot/initrd title Debian Linux testing/unstable Kernel 2.2.20 kernel (hd0,1)/boot/vmlinuz-2.2.20 root=/dev/hda2 splash=silent vga=0x31a title (Remote) Debian Linux testing/unstable Kernel 2.2.20 kernel (hd0,1)/boot/vmlinuz-2.2.20 root=/dev/hda2 console=tty0 console=ttyS0,9600n8 title floppy root (fd0) chainloader +1 title failsafe kernel (hd0,2)/boot/vmlinuz.shipped root=/dev/hda3 showopts ide=nodma apm=of f acpi=off vga=normal nosmp noapic maxcpus=0 3 initrd (hd0,2)/boot/initrd.shipped title L4Linux -+- Hello World kernel (hd0,2)/denny/Dresden/rmgr -sigma0 modaddr 0x02000000 module (hd0,2)/denny/Dresden/main -nokdb -nowait -comspeed 9600 -comport 1 module (hd0,2)/denny/Dresden/sigma0 module (hd0,2)/denny/Dresden/glinux root=/dev/hda3 module (hd0,2)/denny/Dresden/hello title L4Linux-------------------><8------------------------ Apols I have not gone the netboot road, as "all"! my boxes are totally different there are too many risks for cross compiling, I compile for the OS and box where it loads from. Host OS is SuSE8.2 with linux22 compiled under 2.95.3 and l4 + the rest under 3.2 (i.e. reverted), all compiles terminated OK, all libraries & dependencies found to the best of my ability. The same error has stopped me for some 24 hours; I have been round the houses tidying up all I can find here so I await your advice with eagerness. In the meantime, to get a bit nearer, I have the Debian system ready for a similar assault when I have my energy restored... TIA David Denny

3 3

Driver using DDE
by Chris Lambert 26 Aug '03

26 Aug '03

Hello, we try to implement drivers for DROPS using the DDE, but we only have the sounddriver described in the diploma thesis of Christian Helmuth. Are there other sample drivers (smaller) available for us to see how to use DDE? It's part of a project at Operating Systems Chair at University of Saarland. Chris Lambert Markus Pister Marc Schlickling

2 1

Thanks all
by David Denny 25 Aug '03

25 Aug '03

Well we now have fiasco booting Hello, and more or less satisfactory boots of cpufreq and pingpong, on SuSE8.2 with reverted compiler (3.2). Thanks ALL for your assistance. My next steps are to get a L4Linux working on SuSE8,2 and then repeat for Debian. The side effects are of course swapping compilers and libraries in and out of the host OS. I should like to see after that if I can get the DoPE demo working properly. I am guessing so far that it may be some underlying library or compilation incompatibility. I have checked that vbeset, vbeprobe and testvbe work in grub, so it /doesn't/ seem to be the machine, and it's likely therefore that the issue has to be somewhere in the compiled binaries on the demo diskette. I'm wondering therefore if at some time the sources for vscrtest and its prereqs might be made available? (I will speak to Norman about DoPE). Thanks again. I hope to be back when I have got the next bits working successfully. Kind Regards & thanks all once again. David D

1 0

DROPS make in Debian Testing, failed from linux22 drivers
by David Denny 23 Aug '03

23 Aug '03

Hi Hackers After failing to "make hello" from the website, I tried "make" Drops from the docs page, however this has also crashed... see snip line. gcc3.3.1 again. debian/testing TIA David ----8><---------------------------------------------------------------------------------- In file included from /home/drops/linux22/include/asm/l4arch/floppy.h:4, from /home/drops/linux22/include/asm/floppy.h:4, from floppy.c:201: /home/drops/linux22/include/asm-i386/floppy.h:78:8: missing terminating " character /home/drops/linux22/include/asm-i386/floppy.h:99:9: missing terminating " character In file included from /home/drops/linux22/include/linux/blkdev.h:6, from /home/drops/linux22/include/linux/blk.h:4, from floppy.c:206: /home/drops/linux22/include/linux/genhd.h: In function `ptype': /home/drops/linux22/include/linux/genhd.h:83: warning: deprecated use of label at end of compound st atement make[5]: *** [floppy.o] Error 1 make[5]: Leaving directory `/home/drops/linux22/drivers/block' make[4]: *** [first_rule] Error 2 make[4]: Leaving directory `/home/drops/linux22/drivers/block' make[3]: *** [_subdir_block] Error 2 make[3]: Leaving directory `/home/drops/linux22/drivers' make[2]: *** [_dir_drivers] Error 2 make[2]: Leaving directory `/home/drops/linux22' make[1]: *** [vmlinux] Error 2 make[1]: Leaving directory `/home/drops/linux22' make: *** [../linux22] Error 2 dresden@chavin:/home/drops/l4$

2 1

Executable Subset
by David Denny 23 Aug '03

23 Aug '03

Hello Hackers again.. I've reconstituted my Fiasco box with a Debian (Stable) and a SuSE (8.0) dual boot. My aim is to have a workable approximation to the Dresden configurations using Debian, while the SuSE version will enable me to help test on that platform. I have acquired gcc3.2 and binutils to match and those will be installed shortly. I have a question for the group. My disk space is limited. I can build on this computer but it would be ideal if after building I could move the bulk of the l4, ($BUILDDIR), oskit, and the rest onto another machine, retaining on my "Fiasco" box only those files needed for a running installation, i.e. kernel modules, libraries, and whatever else. (It goes without saying that I need to reserve space for any linux executables that I intend to run on top of Fiasco) I'm happy to experiment with this question, but if the group already possesses a list of executables, libraries, and so on, it would be nice to start from there. OTOH if you don't then perhaps I could make a contribution to the project by creating this list. -- ____________________________________________ http://www.operamail.com Get OperaMail Premium today - USD 29.99/year Powered by Outblaze

3 2

auth.idl
by Etienne Robillard 20 Aug '03

20 Aug '03

Hi Hackers, on implementing the auth module (currently running on mach_port_t and all) in idl4 grammar with L4 ipc/syscalls. Question is how the relationship between mach_port_t would affect l4_threadid_t and folks ? The following is not currently appropriate for any of the Hurd/Mach RPC device or L4 syscalls: module auth { /* this is the generic auth module implementation for Hurd */ interface auth_getids /* generic api for _ids */ { int l4_ids_t([out] static l4_threadid_t ids_t, [out] &idarray_t /* some foo here je je */); }; This is only a partial implementation of the auth.def interface - but since the module is so small; it may be easier to port with l4_* components. It does use the idl4 fast compiler and is expected to be loaded as a root_task/clan_ipc ;) The brackets are for compatibility with DCE/DICE. etienne ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca /* experimental (and partial too) reincarnation of the 'Hurd' auth server on the L4 microkernel. It should be loaded as the root_task .. I need to know however the exact translation (idl grammar of the auth server on L4) that is required in order to get the module functionning ( or at least to compile! ) please no flame. */ module auth { interface auth_getids { int get_ids([out] static l4_threadid_t ids_t, [out] &idarray_t); };

2 1

Video Issue with DROPS demo
by David Denny 14 Aug '03

14 Aug '03

Hello Hackers I have a video problem with this machine running the Fiasco demo and my compiled fiasco modules. The latter hang on boot, or appear to do so. the demo appears to run, but black screen, and 1-pixel deep band of pretty coloured dots right at the top. Compaq pII400 deskpro sff. ATI3D Rage Pro AGP 1x/2x I will appreciate knowing which parts of which files might be worth looking at. My belief is that it's a vesa/framebuffer setting. Normal Linux runs X perfectly (both Deb and SuSE), and the (sorry) Pistachio demo boots and runs properly. SO, it has to be something simple. Grub settings and menu taken from Dresden website. TIA David -- ____________________________________________ http://www.operamail.com Get OperaMail Premium today - USD 29.99/year Powered by Outblaze

2 1

memory descriptor overflow was RE: [RMGR] kernel entry point and pistachio
by Etienne Robillard 11 Aug '03

11 Aug '03

--- Volkmar Uhlig <volkmar(a)ira.uka.de> wrote: > You can't use RMGR with Pistachio--why would you...? O.K - maybe it was not a very good idea.. you decide ;) I'm getting a memory descriptor overflow (m=200; n=200), while trying to _boot_ the kernel. 'esquisse' of whats going on: RMGR -- configuring s0 / roottask RMGR -- can't detect L4 kernel -- assuming UKA kernel. RMGR -- booting /boot/ia32-kernel... pistachio on foo@bar ... init_arch->boot_mem_init->kmem_init->activate_gdt(); several remaps() occurs... entering KDB, locked, blood shed ;) You can see in init.cc (pistachio-0.1) the following line : i < get_kip()->mem_info.get_num_descriptors(); i++ (...) hint: It would be great if the kernel could return to RMGR but its too early to tell - for now Volkmar is right and thus no RMGR can be used with X.2 ;) etienne ===== iD ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

Re: Make error in sys_ipc_wrapper
by daviddenny＠chavin.net 01 Aug '03

01 Aug '03

Udo, Thanks.. I tried make clean followed by make... this stopped in the same place NB I'm using the CVS version, downloaded on Saturday or Sunday last, I'm not sure. Bearing in mind my previous problem with tempfile, I am wondering if there is a linux distro issue involved. I'm using SuSE8.0 which has a kernel level of 2.4.18. When looking at UML (IIRC), I remember seeing somewhere that the SuSE kernel is a bit customised. Maybe this is the problem and there are sources missing in my distro that Fiasco/L4 expects. Do I gather that tu-dresden relies on debian? Maybe I should consider installing a debian linux instead, on this machine. TIA David D "Udo A. Steinberg" <us15(a)os.inf.tu-dresden.de>@os.inf.tu-dresden.de Sent by: l4-hackers-bounces(a)os.inf.tu-dresden.de 15:05 ZE2 Today To: David Denny <david(a)yaravi.com> cc: "l4-hackers(a)os.inf.tu-dresden.de" <l4-hackers(a)os.inf.tu-dresden.de> Subject: Re: Make error in sys_ipc_wrapper On Wed, 30 Jul 2003 06:30:38 +0100 David Denny (DD) wrote: DD> I attach glpbalconfig.out & last piece of compile log & look forward to finding out what I have overlooked Hi, I've tried your configuration and I can build it just fine here. I'm using the current CVS version. What version are you using? CVS or the Fiasco-1.0 release + patches from our website? Also, have you tried a "make cleanall" and then a "make"? -Udo. -- Gleichgültigkeit ist die mildeste Form der Toleranz. [Karl Jaspers] _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

6 6

Make error in sys_ipc_wrapper (Michael Hohmuth)
by David Denny 01 Aug '03

01 Aug '03

Re --8><--------------------------------------------- This could also be a problem with `preprocess' or the Perl interpreter it uses. Could you try the following: % cd l4/tool/preprocess % cvs update -d [ Only if you use a copy checked out from our CVS ] % make test ---------------------------------------------8><-- Certainly, I'll do this & send result. I do use the CVS versions from your site, without exception. Thanks for the help David -- ____________________________________________ http://www.operamail.com Get OperaMail Premium today - USD 29.99/year Powered by Outblaze

1 0

Sawmill defunct?
by Peter Busser 31 Jul '03

31 Jul '03

Hello, I'm interested in Sawmill, but could not find any place to download it and the e-mail address on the web site does not work. Does anyone know if the project still exists and if so, wether there is a Sawmill mailing list and/or download page somewhere. I'm new to L4 and would like to learn more about microkernels by playing around a bit with the various versions. But it looks like that, except for the L4 kernels, there is not much to play with. Or is there? Groetjes, Peter Busser -- The Adamantix Project Taking trustworthy software out of the labs, and into the real world http://www.adamantix.org/

3 4

Is there an L4Linux v2.4?
by Peter Busser 30 Jul '03

30 Jul '03

Hello, Does anyone know if there is an L4Linux v2.4 available? And if not, if someone is working on it and when it will be out? Groetjes, Peter Busser

2 1

Re: Make error in sys_ipc_wrapper
by Udo A. Steinberg 30 Jul '03

30 Jul '03

On Wed, 30 Jul 2003 06:30:38 +0100 David Denny (DD) wrote: DD> I attach glpbalconfig.out & last piece of compile log & look forward to finding out what I have overlooked Hi, I've tried your configuration and I can build it just fine here. I'm using the current CVS version. What version are you using? CVS or the Fiasco-1.0 release + patches from our website? Also, have you tried a "make cleanall" and then a "make"? -Udo. -- Gleichgültigkeit ist die mildeste Form der Toleranz. [Karl Jaspers]

1 0

Make error in sys_ipc_wrapper
by David Denny 30 Jul '03

30 Jul '03

Hi Hackers Wondering if anyone has a quick answer for this Make error ---------------------8><---------------------------------------------------------------------------- thread-ipc.o: In function `Thread::handle_page_fault_pager(unsigned int, unsigned int)': /home/chavin/TUDresden/l4/kernel/fiasco/src/kern/thread-ipc.cpp:786: undefined reference to `Thread::do_send(Thread *, L4_timeout, Sys_ipc_frame *)' thread-ipc.o: In function `sys_ipc_wrapper': /home/chavin/TUDresden/l4/kernel/fiasco/src/kern/thread-ipc.cpp:968: undefined reference to `Thread::do_send(Thread *, L4_timeout, Sys_ipc_frame *)' make[3]: *** [kernel.image] Error 1 ---------------------8><---------------------------------------------------------------------------- Happy to provide more diagnostics if required. TIA David Denny

2 1

Semantics of extraordinary scheduling
by Robert Kaiser 29 Jul '03

29 Jul '03

Hello, I have a question about extraordinary scheduling in L4: The specification is unclear about if/how the thread's scheduling priorities are involved in the game. What is the intended behavior if -say- a high priority thread donates its remaining timeslice to a lower-priority one. If I understand the code correctly, what happens in existing L4 implementations is that 1. The recipient gets to execute regardless of it's priority, i.e. even if there are runnable threads that have a higher priority than the recipient, that recipient still gets the CPU. 2. If, while the recipient is running on its donated time slice, another, higher priority thread becomes ready (e.g. due to an interrupt), the recipient is preempted. So far so good, but, when that preempting thread blocks again, the scheduler selects the next thread solely according to priority, i.e. if the recipient does not have the highest priority, another thread will run and the recipient may effectively loose its donated time prematurely due to an unrelated event (interrupt). My naive gut feeling suggests that either 1. or 2. are not really the intended behavior. Am I missing something ? Is anybody using this mechanism at all ? Many thanks for any insights Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO AG Am Pfaffenstein 14 phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

1 0

Stupid newb can't "make -C l4 config"- THANKS
by David Denny 28 Jul '03

28 Jul '03

Well, I woke up with the realisation that maybe there was a src for debianutils at debian.org- and so there was.. have installed tempfile, all OK now but /slightly embarrassed/ Sorry to bother you all; but "Thanks Adam" for the swift response. I now have a proper config and an almost successful make. I will hack the latter somewhat before coming back to the list. Cheers All DD

2 1

Stupid newb can't "make -C l4 config" ..
by David Denny 26 Jul '03

26 Jul '03

Hullo L4 Stuck at an early fence:: usually I can overcome these things. make -C l4 config fails with /bin/sh: tempfile: command not found have been looking for it everywhere. seemingly part of Python, I have Python 2.2 and tbh my binutils is a bit lower than specified but I would have thought this insignificant. Google not much help either. Clean install of SuSE linux 8.0, kernel 2.4.18 Would seriously love to get this going as I have a little project that could go rather nicely on top of it, but am totally lost with this silly command. TIA David Denny

2 1

ANNOUNCE: L4Env version 0.1
by DROPS-Team 01 Jul '03

01 Jul '03

The DROPS team is happy to announce the first release of the L4Env programming environment. L4Env is a programming environment for application development on top of the L4 microkernel family. It is developed as a part of the Dresden Real-Time Operating System (DROPS). Prior to L4Env, most L4 applications had their very own idea about the environment (libraries, interfaces and so on) in which they were executed. Almost every programmer had his own set of libraries he used to build his applications, which resulted in huge problems if someone tried to combine components developed by different authors. Frequent problems were conflicting implementations of common functions (like printf) or conflicts caused by the lack of a central management of resources like threads or virtual memory. The intention of L4Env is to define a set of functions which describe a minimal environment. This minimal environment is available for every L4 application. Hence, all applications and especially all libraries can use these functions. Libraries which are intended to be used by many different applications should only use these functions to avoid dependencies to other libraries. L4Env also decreases the dependencies to a certain L4 API or hardware architecture, making applications more portable. L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops(a)os.inf.tu-dresden.de. Source distributions, documentation, and other online resources can be found on the L4Env website: http://os.inf.tu-dresden.de/l4env/ The DROPS Team Operating Systems Group University of Technology Dresden, Germany

5 7

Re: l4-hackers Digest, Vol 3, Issue 10
by Markkhudd＠aol.com 24 May '03

24 May '03

Hong Kong (1)

1 0

root task - debugging kernel
by Etienne Robillard 22 May '03

22 May '03

Hi, How do we define printf in ia32-v4 ? I see there is a print.cc implementation but it won't be used(?) for the linking stage even with "#define CONFIG_KDB y" and or "#define CONFIG_VERSION_X0 1" in $(OBJ)/config.h... Besides, kickstarting from grub (output to screen) does work until the "Launching kernel stage" ; then it freezes without warnings :-) my menu.lst looks like this : root (hd0,1,a) kernel= /boot/ia32-kernel module=/libexec/l4/kickstart module= /libexec/l4/sigma0 module= /libexec/l4/pingpong cya etienne ===== iD ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

6 5

RE: None
by Volkmar Uhlig 21 May '03

21 May '03

> -----Original Message----- > From: Andreas Rottmann [mailto:a.rottmann@gmx.at] > Sent: Wednesday, May 21, 2003 8:27 PM > > I wonder why Pistachio needs VME, however. Maybe someone can give a > hint? The hint is that it is not needed right now. The check is going to be removed with the next revision. We just wanted to keep track of all the boch users (just kidding...) - Volkmar

1 0

Re: None
by Andreas Rottmann 21 May '03

21 May '03

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: >> Many thanks for your help, I'm sorry if this seems dumb but I really am >> confused with all the different parts of l4ka and l4hurd. As soon as I >> get all of this working, I am going to put together a complete guide to >> setting up bochs with l4ka, combining all of the above resources. That's >> *if* I get it working, and understand why! > > You may want to try running L4Ka::Pistachio/x86 under the most recent > bochs. We're planning to implement l4hurd on top of Pistachio, not > Hazelnut. > I tried that, and FWICT, Pistachio needs the VME processor capapbility (virtual mode extensions, see http://x86.ddj.com/articles/vme1/vme_overview.htm), which bochs doesn't provide. here is the relevant code (pistachio/kernel/src/glue/v4-ia32/init.cc): --------------------- /** * checks the IA32 features (CPUID) to make sure the processor * has all necessary features */ static void SECTION(".init.cpu") check_cpu_features() { u32_t req_features = IA32_FEAT_FPU | IA32_FEAT_VME | IA32_FEAT_PSE; [...] if ((req_features & avail_features) != req_features) { printf("CPU does not support all features (%x) -- halting\n", req_features); ------- I wonder why Pistachio needs VME, however. Maybe someone can give a hint? Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann(a)gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war!

2 1

(no subject)
by Yu Neil 19 May '03

19 May '03

hello: how we identify the sigma0 server in l4_threadid_t format ? ( the sigma0.id.* is what?) Neil Yu _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/

2 1

Re: Re: Neukundenakquise
by Cherry George Mathew 17 May '03

17 May '03

Farid> Whoever stopped this would be the Hero of the Day(TM) ;) And I certainly hope somebody cleans up the archives. Googling can be a pain with all the noise. Regards, Cherry.

1 0

Re: Neukundenakquise
by Farid Hajji 17 May '03

17 May '03

Hi l4-hackers admins: > SIE HABEN DAS PRODUKT - WIR IHRE ZUK\NFTIGEN KUNDEN. > > http://www.Adress-Schmiede.de I'm also getting a lot of SPAM from those people. They seem to misuse a T-Online AG dialin account to spread their stuff: > Received: from os.inf.tu-dresden.de (pD9E8B8C6.dip.t-dialin.net > [217.232.184.198])h4H0DdhF006363 > for <l4-hackers(a)os.inf.tu-dresden.de>; > Sat, 17 May 2003 02:13:39 +0200 (MEST) This looks similar on all SPAMs that I've got on multiple E-Mail addresses. They use different IP addresses from the same pool. You may contact T-Online AG regarding this. I'm pretty sure that this is not in accordance with their (T-Online's) AUP. Whoever stopped this would be the Hero of the Day(TM) ;) > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.

1 0

spamfilter on mailinglist
by Remco Post 16 May '03

16 May '03

Hi all, ok, spmmers found us, unfortunately, could the listowner apply some spamassasin magic to incoming mails? It would be greatly appriciated.... -- Met vriendelijke groeten, Remco Post SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167 "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams

2 1

compiling L4Env with oskit for Fiasco and L4Linux
by Etienne Robillard 06 May '03

06 May '03

Hello everyone, My name is Etienne Robillard and I am studying Art in college. I don't have yet any degree in computers science, whatsoever. What I am attempting to do is to build/boot L4Linux (and on another time The Hurd, while I'm at it...) on a typical x86 machine, Pentium III with 384mb of sdram. oskit = oskit60 (the old version modified for l4 with patches) gcc = crossgcc 2.95.2 (no libgcc2.a) with pthread-elf support, i386/linux emulation os = freebsd4.7-p8 (with libc_r/) make = gmake target = i586-l4-linux (just for fun...) build= i386-unknown-freebsd4.7 binutils = version 2.13.2.1 as root in $(L4DIR); gmake hello : gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/flux' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/flux' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libc' i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/bcopy.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/bcopy16.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/bzero.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/gcc.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/i16_bcopy.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/i16_bzero.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/memset.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/ntoh.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libc/x86/proc_reg.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/setjmp.S ar rv libmc.a bcopy.o bcopy16.o bzero.o gcc.o i16_bcopy.o i16_bzero.o memset.o ntoh.o proc_reg.o setjmp.o r - bcopy.o r - bcopy16.o r - bzero.o r - gcc.o r - i16_bcopy.o r - i16_bzero.o r - memset.o r - ntoh.o r - proc_reg.o r - setjmp.o ranlib libmc.a cp libmc.a ../lib/libmc.a gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libc' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/liblmm' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/liblmm' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libexec' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libexec' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libdiskpart' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libdiskpart' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libkern' i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_critical.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_gdt_load.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_idt_load.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_paging_init.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libkern/x86/base_stack.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libkern/x86/base_trap_inittab.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_tss_init.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/base_tss_load.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/cpuid.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libkern/x86/gdb_copy.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libkern/x86/pc/gdb_pc_com_intr.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/gdb_trap.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pdir_dump.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pdir_map_page.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pdir_map_range.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pdir_prot_range.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pdir_unmap_range.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pc/pic.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/ptab_alloc.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/ptab_dump.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/ptab_free.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/pc/reset.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libkern/x86 -I../libkern/x86/trap -I../libkern/x86/pc -I../libkern -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libkern/x86/trap_dump.c ar rv libkern.a base_critical.o base_gdt_load.o base_idt_load.o base_paging_init.o base_stack.o base_trap_inittab.o base_tss_init.o base_tss_load.o cpuid.o gdb_copy.o gdb_pc_com_intr.o gdb_trap.o pdir_dump.o pdir_map_page.o pdir_map_range.o pdir_prot_range.o pdir_unmap_range.o pic.o ptab_alloc.o ptab_dump.o ptab_free.o reset.o trap_dump.o r - base_critical.o r - base_gdt_load.o r - base_idt_load.o r - base_paging_init.o r - base_stack.o r - base_trap_inittab.o r - base_tss_init.o r - base_tss_load.o r - cpuid.o r - gdb_copy.o r - gdb_pc_com_intr.o r - gdb_trap.o r - pdir_dump.o r - pdir_map_page.o r - pdir_map_range.o r - pdir_prot_range.o r - pdir_unmap_range.o r - pic.o r - ptab_alloc.o r - ptab_dump.o r - ptab_free.o r - reset.o r - trap_dump.o ranlib libkern.a cp libkern.a ../lib/libkern.a gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libkern' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libsmp' i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libsmp/x86 -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libsmp/x86/boot.S i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libsmp/x86 -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libsmp/x86/critical.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libsmp/x86 -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libsmp/x86/linux-smp.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libsmp/x86 -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libsmp/x86/smp.c ar rv libsmp.a boot.o critical.o linux-smp.o smp.o r - boot.o r - critical.o r - linux-smp.o r - smp.o ranlib libsmp.a cp libsmp.a ../lib/libsmp.a gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libsmp' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libmemdebug' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libmemdebug' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libfdev' i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DDEBUG -I. -I../libfdev -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall irq.c irq.c:97: warning: `fdev_intr_enable' declared inline after being called irq.c:103: warning: `fdev_intr_disable' declared inline after being called i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DDEBUG -I. -I../libfdev -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD irqstubs.S /var/tmp/ccMEqA1O.s: Assembler messages: /var/tmp/ccMEqA1O.s:421: Warning: using `%ecx' instead of `%cx' due to `l' suffix /var/tmp/ccMEqA1O.s:422: Warning: using `%ecx' instead of `%cx' due to `l' suffix /var/tmp/ccMEqA1O.s:423: Warning: using `%ecx' instead of `%cx' due to `l' suffix i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DDEBUG -I. -I../libfdev -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall sched.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DDEBUG -I. -I../libfdev -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall softintr.c i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DDEBUG -I. -I../libfdev -I- -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall timer.c ar rv libfdev.a irq.o irqstubs.o sched.o softintr.o timer.o r - irq.o r - irqstubs.o r - sched.o r - softintr.o r - timer.o ranlib libfdev.a cp libfdev.a ../lib/libfdev.a gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libfdev' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libfdev_linux' gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libfdev_linux' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libfdev_linux' i586-l4-linux-gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -DOSKIT -D__KERNEL__ -DDEBUG -I. -I../libfdev_linux -I../libfdev_linux/net -I../libfdev_linux/block -I../libfdev_linux/pci -I../libfdev_linux/scsi -I- -I../libfdev_linux/include -I.. -I.. -I../flux/c -nostdinc -g -O2 -Wall ../libfdev_linux/scsi/53c7,8xx.c In file included from ../libfdev_linux/include/linux/string.h:40, from ../libfdev_linux/include/asm/termios.h:271, from ../libfdev_linux/include/linux/termios.h:5, from ../libfdev_linux/include/linux/tty.h:10, from ../libfdev_linux/include/linux/sched.h:25, from ../libfdev_linux/scsi/53c7,8xx.c:228: ../libfdev_linux/include/asm/string.h: In function `__constant_memcpy': ../libfdev_linux/include/asm/string.h:408: warning: control reaches end of non-void function ../libfdev_linux/include/asm/string.h: In function `__constant_c_and_count_memset': ../libfdev_linux/include/asm/string.h:557: warning: control reaches end of non-void function In file included from ../libfdev_linux/scsi/53c7,8xx.c:230: ../libfdev_linux/include/linux/bios32.h: At top level: ../libfdev_linux/include/linux/bios32.h:58: warning: type defaults to `int' in declaration of `pcibios_write_config_dword' ../libfdev_linux/scsi/53c7,8xx.c: In function `internal_setup': ../libfdev_linux/include/asm/string.h:105: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:105: fixed or forbidden register 4 (si) was spilled for class SIREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `NCR53c7x0_init': ../libfdev_linux/include/asm/string.h:402: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:402: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `normal_init': ../libfdev_linux/include/asm/string.h:495: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:495: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `NCR53c8x0_init_fixup': ../libfdev_linux/include/asm/string.h:402: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:402: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `NCR53c8xx_dsa_fixup': ../libfdev_linux/include/asm/string.h:366: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:366: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `abnormal_finished': ../libfdev_linux/scsi/53c7,8xx.c:2137: warning: suggest explicit braces to avoid ambiguous `else' ../libfdev_linux/scsi/53c7,8xx.c: In function `NCR53c8x0_dstat_sir_intr': ../libfdev_linux/include/asm/string.h:402: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:402: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `create_cmd': ../libfdev_linux/include/asm/string.h:403: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:403: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/include/asm/string.h:403: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:403: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `intr_scsi': ../libfdev_linux/include/asm/delay.h:43: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:43: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/include/asm/delay.h:20: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:20: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `print_insn': ../libfdev_linux/include/asm/string.h:287: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:287: fixed or forbidden register 5 (di) was spilled for class DIREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `ncr_scsi_reset': ../libfdev_linux/include/asm/delay.h:43: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:43: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/include/asm/delay.h:20: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:20: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `ncr_halt': ../libfdev_linux/scsi/53c7,8xx.c:6233: warning: suggest explicit braces to avoid ambiguous `else' ../libfdev_linux/include/asm/delay.h:43: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:43: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/include/asm/delay.h:20: Invalid `asm' statement: ../libfdev_linux/include/asm/delay.h:20: fixed or forbidden register 0 (ax) was spilled for class AREG. ../libfdev_linux/scsi/53c7,8xx.c: In function `dump_events': ../libfdev_linux/include/asm/string.h:402: Invalid `asm' statement: ../libfdev_linux/include/asm/string.h:402: fixed or forbidden register 2 (cx) was spilled for class CREG. ../libfdev_linux/scsi/53c7,8xx.c: At top level: ../libfdev_linux/scsi/53c7,8xx.c:693: warning: `request_synchronous' defined but not used ../libfdev_linux/scsi/53c7,8xx.c:741: warning: `request_disconnect' defined but not used ../libfdev_linux/scsi/53c7,8xx.c:5395: warning: `ncr_state' defined but not used gmake[1]: *** [53c7,8xx.o] Error 1 gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libfdev_linux' gmake: *** [libfdev_linux/all.MAKE] Error 2 In order to get there, I had to undefined HAVE_CODE16 in $(OSKIT)/flux/config.h. Otherwise, I would have this bug : gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/flux' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/flux' gmake[1]: Entering directory `/home/manoya/build/l4oskit/l4/oskit/libc' gcc -c -MD -DHAVE_CONFIG_H -DDEBUG -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/i16_bcopy.S /tmp/ccqgmwoi.s: Assembler messages: /tmp/ccqgmwoi.s:235: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:236: Error: `12(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:238: Error: `16(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:239: Error: `(%esi,%edx)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:242: Error: `(%edi,%edx)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:259: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:278: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:291: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccqgmwoi.s:292: Error: `12(%ebp)' is not a valid 16 bit base/index expression gmake[1]: *** [i16_bcopy.o] Error 1 gmake[1]: Leaving directory `/home/manoya/build/l4oskit/l4/oskit/libc' gmake: *** [libc/all.MAKE] Error 2 I dont know if this is a bug 'cause, ain't qualified ;) really... As a result, I am quite lost in space with the asm part. But, I was asking myself if 1) this is due to an improper crosscompiler setup (compiler doesnt have libgcc2.a subroutines... my fault) Will work on that for now on. 2) because I have undef HAVE_CODE16, my i16_bcopy object will fail bit-copying inline functions that need 16 bit index base ? 3) "warning: control reaches end of non-void function" and "fixed or forbidden register 2 (cx) was spilled for class CREG" Yeah. right. Bring it Linda ! Here is for your convenience a sample of the contents of $(OSKIT)/libfdev_linux/include/asm/string.h:408 #define __HAVE_ARCH_MEMCPY #define memcpy(t, f, n) \ (__builtin_constant_p(n) ? \ __constant_memcpy((t),(f),(n)) : \ <------ n=count ? __memcpy((t),(f),(n))) /* I have tried to change (n) to (count) with similar syndromes; but something's telling me that Linus know what he`s doing while I seriously doubt my proefficiency in that domain... */ Also, I dont have an Internet connection at home... Therefore, I got very, very old parts (before 1.0) of the Fiasco �-kernel... At last, this issue in lfdev_linux might be solved already(?), which would be nice, but I haven't found any references to that neither in the 2001 mailing-list or in the 2002. Kind regards, Etienne Robillard Person who say it cannot be done should not interrupt person doing it. --Chinese Proverb ===== iD ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

about l4_thread_ex_regs()
by Yu Neil 05 May '03

05 May '03

hello: i execute the l4_thread_ex_regs(...) systemcall, then the stack been pushed 0x38 byte data (esp -0x38), what`s that ? most serious is if i execute the l4_thread_ex_regs( dest_thread_id, child,... ) systemcall then the |child| running ,but if i execute l4_myself() in |child|, the return value is not equal to dest_thread_id, is that means i can`t specific the dest thread id or it`s unnecessary to spicify the dest thread id in the caller thread, but managed by |child| itself ? Neil Yu _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn

1 0

Re: Problems compiling from CVS
by Daniel Koch 04 May '03

04 May '03

> Subject: Re: Problems compiling from CVS > To: l4-hackers(a)os.inf.tu-dresden.de > Message-ID: <20030503220824.GA16869(a)os.inf.tu-dresden.de> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > > On Sun May 04, 2003 at 00:42:03 +0200, Daniel Koch is going to write: > > when I try to compile the hello world servers with "make hello" from > > your newest cvs version I get the following error: > > > > In file included from ../cfg-parse.y:320: > > <stdout>:23:20: stdint.h: Datei oder Verzeichnis nicht gefunden > > Do you have the libc development package with the header files installed > (something like libc6-dev)? > > > > > > > Adam Hi Adam, the stdint.h file is where it should be: /usr/include/stdint.h skywalker:/usr/include# ls -la stdint.h -rw-r--r-- 1 root root 8545 2003-04-19 20:56 stdint.h skywalker:/usr/include# I tried compiling it as root, but its just the same problem Daniel

2 4

Re:Re: Problems compiling from CVS
by Daniel Koch 04 May '03

04 May '03

>Do you have the libc development package with the header files >installed >(something like libc6-dev)? Yes,libc6-dev 2.3.17. Should I remove this package and use the standard libc6 instead ? Daniel

2 1

Problems compiling from CVS
by Daniel Koch 04 May '03

04 May '03

Hello, when I try to compile the hello world servers with "make hello" from your newest cvs version I get the following error: ... Compiling cfg-parse.o LD_PRELOAD= GENDEP_TARGET=cfg-parse.o GENDEP_BINARY= gcc -c -DSYSTEM_x86_586_l4v2 -DARCH_x86 -DCPUTYPE_586 -DL4API_l4v2 -I../../../server/src -I. -I../../../../../include/x86/l4v2 -I/home/drops/include/x86/l4v2 -I../../../../../include/x86 -I/home/drops/include/x86 -I../../../../../include -I/home/drops/include -nostdinc -I../../../../../../oskit -I../../../../../../oskit/flux/c -I/home/drops/include -I/home/drops/include/flux/c -I/usr/lib/gcc-lib/i386-linux/3.2.3//include -g -O2 -march=i586 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wno-unused -Wno-parentheses cfg-parse.c -o cfg-parse.o In file included from ../cfg-parse.y:320: <stdout>:23:20: stdint.h: Datei oder Verzeichnis nicht gefunden In file included from ../cfg-parse.y:320: <stdout>:2086: warning: no previous prototype for `yyget_lineno' <stdout>:2095: warning: no previous prototype for `yyget_in' <stdout>:2103: warning: no previous prototype for `yyget_out' <stdout>:2111: warning: no previous prototype for `yyget_leng' <stdout>:2120: warning: no previous prototype for `yyget_text' <stdout>:2129: warning: no previous prototype for `yyset_lineno' <stdout>:2141: warning: no previous prototype for `yyset_in' <stdout>:2146: warning: no previous prototype for `yyset_out' <stdout>:2151: warning: no previous prototype for `yyget_debug' <stdout>:2156: warning: no previous prototype for `yyset_debug' <stdout>:2162: warning: no previous prototype for `yylex_destroy' make[4]: *** [cfg-parse.o] Fehler 1 make[4]: Leaving directory `/home/daniel/Projekt/DROPS/l4/pkg/rmgr/server/src/OBJ-x86_586-l4v2' make[3]: *** [all] Fehler 2 make[3]: Leaving directory `/home/daniel/Projekt/DROPS/l4/pkg/rmgr/server/src' make[2]: *** [src] Fehler 2 make[2]: Leaving directory `/home/daniel/Projekt/DROPS/l4/pkg/rmgr/server' make[1]: *** [server] Fehler 2 make[1]: Leaving directory `/home/daniel/Projekt/DROPS/l4/pkg/rmgr' make: *** [hello] Fehler 2 daniel@skywalker:~/Projekt/DROPS/l4$ Im using gcc 3.2.3 on an Athlon system. Any suggestions ? Daniel

2 1

ANNOUNCE: L4Ka::Pistachio version 0.1
by Espen Skoglund 02 May '03

02 May '03

The L4Ka team is happy to announce the first release of the L4Ka::Pistachio microkernel. L4Ka::Pistachio is the latest L4 microkernel developed by the System Architecture Group at the University of Karlsruhe, Germany, in collaboration with the DISY group at the University of New South Wales, Australia. It is the first available kernel implementation of the L4 Version 4 kernel API (currently code-named Version X.2), which is fully 32 and 64 bit clean and provides multiprocessor support. A broad overview of L4Ka::Pistachio and the L4 Version 4 API can be found in: http://l4ka.org/projects/pistachio/pistachio-whitepaper.pdf L4Ka::Pistachio is built from ground up incorporating the research results of the last seven years of microkernel and multi-server research. The code is written in C++ with a strong focus on performance and portability. The first release includes support for many of today's widely used commodity architectures: o Intel IA32 (Pentium and higher) o Intel IA64 (Itanium1) o PowerPC 32bit (IBM 750) o Alpha (21164) o MIPS 64bit (R4000, R5000) The variety of supported architectures makes L4Ka::Pistachio an ideal research and development platform for a wide variety of systems. Additional architectural support for AMD64, ARM, Power4, and UltraSparc is either planned or already in progress. L4Ka::Pistachio is available under the two-clause BSD license. Source and binary distributions, documentation, and other online resources can be found on the L4Ka website: http://l4ka.org/ Within the next few weeks we are going to release L4Linux 2.4.20 which has support for L4Ka::Pistachio/ia32 (besides the old V2 and X.0 APIs). Happy hacking, The L4Ka Development Team

1 0

doxygen?!
by Flonai＠gmx.de 18 Apr '03

18 Apr '03

when i try to compile the the hello server by typing make hello in the l4 building dir, i got an error because i haven't installed doxygen. the problem is that i want to compile fiasco from an linux from scratch system and then using the l4linux microkernel. but doxygen needs xfree and some other progs and i do not want to compile it at this time course i am in an chroot environment with no other linux kernel. i heard doxygen is only need to build documantation files and i do not need them. so is there a way to change one/some makefiles to exclude doxygen. i used the cvs-reposetory (l4,oskit,and then linux22) modules from April 02. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

2 1

Problem compiling Logserver
by Rudolf Weber 18 Apr '03

18 Apr '03

Hello, I miss a l4/env/errno.h when I try to compile the logserver in l4/pkg/log. I'm using the l4v2-API on i586 May this different on the remote cvs ? Greeting Rudolf Weber ... Compiling logserver.o LD_PRELOAD= GENDEP_TARGET=logserver.o GENDEP_BINARY=cpp0 gcc -c -D__USE_L4WQLOCKS__ -D__L4__ -DSYSTEM_x86_586_l4v2 -DARCH_x86 -DCPUTYPE_586 -DL4API_l4v2 -I../../../server/include -I../../../lib/include -I../../../../../include/x86/l4v2 -I/home/rw/l4/current/include/x86/l4v2 -I../../../../../include/x86 -I/home/rw/l4/current/include/x86 -I../../../../../include -I/home/rw/l4/current/include -nostdinc -I../../../../../../oskit10 -I../../../../../../oskit10/oskit/c -I/home/rw/l4/current/include -I/home/rw/l4/current/include/oskit/c -I/usr/lib/gcc-lib/i386-redhat-linux/3.2//include -g -O2 -march=i586 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations ../../../lib/src/logserver.c -o logserver.o ../../../lib/src/logserver.c:17:26: l4/env/errno.h: No such file or directory ../../../lib/src/logserver.c: In function `LOG_channel_open': ../../../lib/src/logserver.c:161: `L4_ENOMEM' undeclared (first use in this function) ../../../lib/src/logserver.c:161: (Each undeclared identifier is reported only once ../../../lib/src/logserver.c:161: for each function it appears in.) ../../../lib/src/logserver.c:162: `L4_ENOTFOUND' undeclared (first use in this function) ../../../lib/src/logserver.c: In function `LOG_channel_write': ../../../lib/src/logserver.c:204: `L4_EIPC' undeclared (first use in this function) ../../../lib/src/logserver.c: In function `LOG_channel_flush': ../../../lib/src/logserver.c:230: `L4_EIPC' undeclared (first use in this function) ../../../lib/src/logserver.c: In function `LOG_channel_close': ../../../lib/src/logserver.c:256: `L4_EIPC' undeclared (first use in this function) -- -- --------------------------------------------------------------- Rudolf Weber http://www.infnet.verein.de/~rw E-Mail: rfweber(a)tesionmail.de

3 2

x2
by Igor Shmukler 08 Apr '03

08 Apr '03

on page 57. lipc conditions - use when it's clear that destination thread runs on the same CPU. does this mean scheduler will traverse the per CPU queue and look for idle destination thread?

1 0

RE: L4 on iPAQ
by Volkmar Uhlig 04 Apr '03

04 Apr '03

> I'm trying to install L4 on the iPAQ (3870). > So far, my iPAQ has the "bootldr" bootloader and Linux installed. > I tried to load the precompiled hazelnut rc2 evaluation suite > for the brutus > evaluation board over serial cable to ram (to address > 0xC1000000) und jumped > to this address (as Volkmar described in nov 2002 on this list). > This didn't work. The iPAQ wrote some digits on the serial > line and crashed. > Has anyone who sucessfully installed L4 on the iPAQ some hints for me? > Must I compile my own custom L4 for the iPAQ? > Or must I use angelboot (I didn't find docs about it in google)? You have to compile your own version of Hazelnut specifically for the iPaq. The Brutus board is not compatible (the memory layout is different). - Volkmar

2 1

L4 on iPAQ
by Dominik Gummel 02 Apr '03

02 Apr '03

Hello, I'm trying to install L4 on the iPAQ (3870). So far, my iPAQ has the "bootldr" bootloader and Linux installed. I tried to load the precompiled hazelnut rc2 evaluation suite for the brutus evaluation board over serial cable to ram (to address 0xC1000000) und jumped to this address (as Volkmar described in nov 2002 on this list). This didn't work. The iPAQ wrote some digits on the serial line and crashed. Has anyone who sucessfully installed L4 on the iPAQ some hints for me? Must I compile my own custom L4 for the iPAQ? Or must I use angelboot (I didn't find docs about it in google)? We need L4 on the iPAQ because we are going to port PERSEUS to it. My part will be the port of Linux 2.4 to L4/ARM (it will be my master thesis). Thanks & Regards, Dominik -- Universität des Saarlandes Department for Computer Science, Cryptography and Security Dominik Gummel email: bofh(a)krypt.cs.uni-sb.de Building 45, Room 536 Im Stadtwald,D-66123 Saarbrücken Tel.: +49(681)302-5608 Fax.: +49(681)302 4631 Fu 0172-6916265 public key http://www-krypt.cs.uni-sb.de/~bofh Fingerprint 5057 7FD9 A0DB 5B92 F1A2 46C1 0070 6200 AAE1 98A9

1 0

Fiasco 1.0 released
by Udo A. Steinberg 02 Apr '03

02 Apr '03

Hello L4 hackers, The Fiasco Team is pleased to announce Fiasco version 1.0, the first official release of the Fiasco L4 microkernel developed at the University of Technology, Dresden. Fiasco currently supports Intel and AMD IA-32 processors (i486 and higher) and implements both version 2 and version X.0 of the L4 interface, as well as several other features such as I/O flexpages and small address spaces. Also included in this release are JDB, the powerful Fiasco kernel debugger, and Fiasco-UX, a user-mode port of Fiasco to the Linux system call interface. For further information please visit the Fiasco homepage at: http://os.inf.tu-dresden.de/fiasco/ Udo Steinberg Operating Systems Group University of Technology Dresden, Germany

1 0

Re: problems running hello in fiasco
by Fabian Sturm 01 Apr '03

01 Apr '03

Hello! Thanks for the reply and sorry that I have to write from a different account but my link to the host in germany seems to be down since two days now. > On Wed Mar 26, 2003 at 07:38:33 +0100, Fabian Sturm wrote: > > > When I then boot into it I see some messages of the RMGR but > > then the system is frozen. > > > > Maybe someone knows what I should try next to track this down? > > Which version of GRUB are you using? Is it "our" version from CVS? Hmm I just took the newest from apha.gnu.org 0.93. I read that you have an own but I thought that is only needed if you have overlapping modules. > How did you configure Fiasco? Could you supply your configuration > (globalconfig.out)!? Sure. I followed the manual and did a make menuconfig in the build directory. I now also tried with the assertions compiled in but none gets triggered so far. Thansk a lot, Fabian # # Automatically generated, don't edit # # Generated on: californium # At: Wed, 26 Mar 2003 02:30:06 +0000 # Linux version 2.4.20 (root@californium) (gcc version 2.95.4 20011002 (Debian p rerelease)) #13 Thu Dec 5 19:48:30 EST 2002 # # Main menu # # # Compiler # CONFIG_USE_GCC=y CONFIG_USE_GCC_3_X=n # # Target Architectures # # # Target platform # CONFIG_IA32=y CONFIG_IA64=n CONFIG_ARM=n CONFIG_UX=n # # Kernel ABI Version # CONFIG_ABI_V2=y CONFIG_ABI_X0=n # # Target processor # CONFIG_IA32_586=y CONFIG_IA32_686=n CONFIG_IA32_K6=n CONFIG_IA32_K6_2=n CONFIG_IA32_K6_3=n CONFIG_ASSEMBLER_IPC_SHORTCUT=y CONFIG_SCHED_RTC=y CONFIG_SLOW_RTC=n CONFIG_DECEIT_BIT_DISABLES_SWITCH=n CONFIG_DISABLE_AUTO_SWITCH=n CONFIG_APIC_MASK=n CONFIG_POWERSAVE_GETCHAR=y CONFIG_X2_LIKE_SYS_CALLS=n CONFIG_SYNC_TSC=n CONFIG_SMALL_SPACES=n # # Kernel Debugging # CONFIG_INLINE=y CONFIG_NDEBUG=y CONFIG_PROFILE=n CONFIG_NO_FRAME_PTR=n CONFIG_KDB=y CONFIG_JDB=y CONFIG_JDB_LOGGING=n CONFIG_MAINTAINER_MODE=n # # Derived symbols # CONFIG_ABI="v2" CONFIG_IA32_TARGET="Intel Pentium" CONFIG_XARCH="ia32" CONFIG_SCHED_PIT=n # # That's all, folks!

4 8

DROPS Konsole
by Daniel Koch 31 Mar '03

31 Mar '03

Hi, finally I managed to get l4linux running without overlapping modules, thanks for the help ! Now I d like to install a Drops console with a con_server, but I don t know where I can download the necessary files. Im also interested in DOpE... id appreciate it if anyone can tell me where to download the files. Daniel

2 1

problems running hello in fiasco
by Fabian Sturm 26 Mar '03

26 Mar '03

Hello! I have a problem running the hello world example on fiasco. I downloaded the latest CVS version from 25.4 of fiasco and compiled it like it is described on the web. Except that the sigma0/rmgr binaries were in l4/bin/x86_586/l4v2 and not directly in l4/bin as described. I then created the following grub entry: title Fiasco, hello world root (hd0,4) kernel=/fiasco/rmgr -sigma0 module=/fiasco/main -nokdb module=/fiasco/sigma0 module=/fiasco/hello When I then boot into it I see some messages of the RMGR but then the system is frozen. Maybe someone knows what I should try next to track this down? Thanks a lot, Fabian Sturm My system is a P3 800Mhz 256MB ram notebook with the Intel i815 chipset. (Vaio vx88) The build environment was Debian Linux 3.0 with gcc 2.95.4. The boot messages were: RMGR: Loading /fiasco/sigma0 RMGR: Loading Kernel fiasco main -nokdb RMGR: check_l4_version 0x00300000 to 0x0044a244 RMGR: detected new_style DD-L4(v2)/Fiasco RMGR: configuring s0: (0x00070000, 0x00096000), start: 0x00070000 RMGR: reserve modules memory range: 0x00200000 to 0x0021053c RMGR: starting kernel /fiasco/main -nokdb proto=0x101ba0 @ 0x00300220 Booting kernel image at 0x302000 entry 0xf0001000 Enabling fully serial nested mode for pic Using the RTC on IRQ 8 (1khz) for scheduling (I hope I don't have introduced errors while copying that down)

2 1

Re: Problem compiling fiasco-ux: ld: entry.o: bad symbol index: 845556
by Udo A. Steinberg 24 Mar '03

24 Mar '03

On 24 Mar 2003 20:58:50 +0100 Rudolf Weber (RW) wrote: RW> Thank you very much, RW> anbei der readelf-output 4udo und das erzeugte entry.o für die echten RW> Programmierer ... RW> Relocation section '.rel.text' at offset 0x10d0 contains 13 entries: RW> Offset Info Type Sym.Value Sym. Name RW> 0000011b 00004101 R_386_32 00000000 base_trap_handler RW> 00000141 00004202 R_386_PC32 00000000 trap_dump_panic RW> 00000150 00004301 R_386_32 00000000 PAGE_FAULT_ADDR RW> 00000179 00004402 R_386_PC32 00000000 thread_page_fault RW> 000001cc 00004502 R_386_PC32 00000000 thread_handle_fputrap RW> 000001e7 00004702 R_386_PC32 00000000 thread_timer_interrupt RW> 000001f7 00004902 R_386_PC32 00000000 thread_timer_interrupt RW> 00000207 00004b02 R_386_PC32 00000000 thread_timer_interrupt RW> 00000211 00004c02 R_386_PC32 00000000 irq_interrupt RW> 00000324 00004d02 R_386_PC32 00000000 dispatch_syscall RW> 00000356 00004f02 R_386_PC32 00000000 call_ipc_short_cut RW> 00000360 0ce6f401 R_386_32 bad symbol index: 000ce6f4 RW> 00000374 00004d02 R_386_PC32 00000000 dispatch_syscall Hallo, Siehe vorletzte gequotete Zeile. Der generierte Code ist kaputt. Ich habe das Problem hier soeben mit gcc 2.95 und gcc 3.2 reproduziert. Bis ich genaueres weiß bzw. einen Patch habe, bitte "Assembler IPC Shortcut" in "make menuconfig" anschalten - dann funktioniert's. -Udo.

1 1

Poblem compiling fiasco-ux: ld: entry.o: bad symbol index: 845556
by Rudolf Weber 23 Mar '03

23 Mar '03

Hello, I tried to compile the current fiasco-ux: make[1]: Entering directory `/home/rw/l4/20030322/l4/kernel/fiasco/build-ux' ==> Linking kernel.image g++ -Wl,--gc-sections,-T../src/kernel.ux.ld -static -o kernel.image boot_info.o boot_info-ux.o cpu-ia32-common.o cpu-ux.o mapdb.o region.o space_context-ia32-ux.o space_context-ux.o space.o space-ia32-ux.o space-ux.o space_index.o space_index_util.o stack.o kmem-ia32-ux.o kmem-ux.o kmem_alloc.o kmem_alloc-ia32-ux.o slab_cache_anon.o kmem_slab_simple.o kmem_slab.o switch_lock.o thread_lock.o helpin g_lock.o cpu_lock.o cpu_lock-generic.o timer.o timer-ia32.o timer-ux.o pic.o pic-ux.o thread_state.o sched.o sched-ia32-ux.o context.o context-ia32-ux.o context-ux.o threadid.o sender.o receiver.o thread.o thread-ia32-ux.o thread-ux.o thread-v2.o thread-syscall.o thread-syscall-v2.o thread-ipc.o thread-msg.o thread-msg-ux.o thread-list.o thread-nolog.o thread-user-ux.o thread-nosmas.o kernel_thread.o kernel_thread-std.o kernel_thread-ux.o thread_util.o kdb_ke.o dirq.o dirq-ia32-ux.o fpu.o fpu-ia32-ux.o fpu-ux.o fpu_alloc.o fpu_state.o map_util.o map_util-ia32-ux.o irq.o irq-ipc.o irq-ux.o globals.o globals-ia32-ux.o main-ia32-ux.o main-ux.o config.o config-ux.o config-ia32-ux.o usermode.o mapped_alloc.o trampoline.o loader.o kern_types.o vmem_alloc.o vmem_alloc-ia32-ux.o vmem_alloc-ux.o panic.o paging.o paging-ia32-ux.o entry_frame.o entry_frame-ia32-common-v2.o startup.o emulation.o hostproc.o task.o task-no-auto-map-kip.o irq_alloc.o libc_support.o long_msg.o long_msg-ux.o entry.o sighandler.o libk.a libamm.a liblmm.a libabi.a libjabi.a libcxx.a libkern.a -lutil /usr/bin/ld: entry.o: bad symbol index: 845556 entry.o: could not read symbols: File format not recognized My System: [rw@fetzi build-ux]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) [rw@fetzi build-ux]$ as -v GNU assembler version 2.13.90.0.2 (i386-redhat-linux) using BFD version 2.13.90.0.2 20020802 [rw@fetzi build-ux]$ ld -v GNU ld version 2.13.90.0.2 20020802 (from Redhat 8.0) Who can fix it ? Greetings Rudolf -- -- --------------------------------------------------------------- Rudolf Weber http://www.infnet.verein.de/~rw E-Mail: rfweber(a)tesionmail.de

3 2

about l4rm
by Yu Neil 22 Mar '03

22 Mar '03

hello every one: where i can find the source code of l4rm ( l4 region maper ) ? and should it work well on x86? Neil Yu _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

2 1

(no subject)
by Yu Neil 20 Mar '03

20 Mar '03

hello every one: where i can find the source code of l4rm ( l4 region maper ) ? and should it work well on x86? Neil Yu _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/

1 0

Problem beim starten von l4linux auf fiasco
by Rudolf Weber 15 Mar '03

15 Mar '03

Hallo, Vorbemerkung: Das starten von glinux bringt einen Fehler überlappender Module, Der Fiasco beginnt da, wo glinux liegt, folgende Änderung habe ich gemacht: --- ./l4/kernel/fiasco/src/Makerules.BOOT.vorrudi 2003-02-25 11:34:43.000000000 +0100 +++ ./l4/kernel/fiasco/src/Makerules.BOOT 2003-03-15 16:13:58.000000000 +0100 @@ -7,7 +7,7 @@ $(BOOT): kernel.o $(OBJ_BOOT) $(LIBKERN) $(MINILIBC) @echo " ... Building boot image" $(LINK_MESSAGE) - $(VERBOSE)$(LD) -Ttext 0x300000 -o $@ $^ $(LIBGCC) \ + $(VERBOSE)$(LD) -Ttext 0x400000 -o $@ $^ $(LIBGCC) \ -defsym checksum_ro=0x`cut -f1 -d' ' $(CHECKSUM)` \ -defsym checksum_rw=0x`cut -f2 -d' ' $(CHECKSUM)` chmod 755 $@ Das starten von grub aus: title L4 fiasco x586 l4v2 L4Linux kernel /l4-20030315-x586/rmgr -sigma0 module /l4-20030315-x586/fiasco.400000 module /l4-20030315-x586/sigma0 module /l4-20030315-x586/glinux root=/dev/hda2 Der glinux startet dann auch, und ganz zum Schluß : Warning: unable to open an initial console Root: ptc is NULL for 00080030 (virt 00080030) and pdir 00400000 at eip: 0050c11b Die Warnung kommt aus dem l4linux als ein open("/dev/console/") schief geht. (offenbar ging wohl das mounten von / nicht :-() Was will mir der rest sagen ? pdir sieht ganz so aus wie die Start-Adresse von Fiasco ? Was habe ich nur falsch gemacht ? Gruß Rudolf Weber -- -- --------------------------------------------------------------- Rudolf Weber http://www.infnet.verein.de/~rw E-Mail: rfweber(a)tesionmail.de

2 1

RE: Problem beim starten von l4linux auf fiasco
by Volkmar Uhlig 15 Mar '03

15 Mar '03

If you have overlapping modules you have no chance whatsoever. So you better fix that ;) I'm not too familiar with the FIASCO kernel boot process, but usually the problem is GRUB, not the kernel. GRUB loads the modules after all loaded elf sections of the initial kernel (which is RMGR in your case). RMGR then tries to load the modules as ELF files and figures out that some elf sections collide with the module locations and barks. This was the reason to add the modaddr feature to GRUB allowing to relocate the load address in main mem. Simply try sticking a modaddr=0x<whatevermemoryyouhave-16MB> after the kernel=rmgr line. Note, that this is only available in the Dresden version of GRUB, not the GNU GRUB (at least AFAIK). So bake yourself a boot floppy from http://os.inf.tu-dresden.de/~fm3/grub.html. The Linux error message is due to the kernel-debugger console in L4Linux. At the end Linux tries to open the console but since it does not support all required features Lx simply falls back to VGA. So this error can be ignored even if it sounds scary. - Volkmar PS: Please post in English -- most subscribers of this list don't understand a word of German (except maybe "Bier" ;) > -----Original Message----- > From: Rudolf Weber [mailto:rfweber@tesionmail.de] > Sent: Saturday, March 15, 2003 8:21 PM > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: Problem beim starten von l4linux auf fiasco > > > Hallo, > > Vorbemerkung: > Das starten von glinux bringt einen Fehler überlappender Module, > Der Fiasco beginnt da, wo glinux liegt, > folgende Änderung habe ich gemacht: > --- ./l4/kernel/fiasco/src/Makerules.BOOT.vorrudi 2003-02-25 > 11:34:43.000000000 +0100 > +++ ./l4/kernel/fiasco/src/Makerules.BOOT 2003-03-15 > 16:13:58.000000000 +0100 > @@ -7,7 +7,7 @@ > $(BOOT): kernel.o $(OBJ_BOOT) $(LIBKERN) $(MINILIBC) > @echo " ... Building boot image" > $(LINK_MESSAGE) > - $(VERBOSE)$(LD) -Ttext 0x300000 -o $@ $^ $(LIBGCC) \ > + $(VERBOSE)$(LD) -Ttext 0x400000 -o $@ $^ $(LIBGCC) \ > -defsym checksum_ro=0x`cut -f1 -d' ' $(CHECKSUM)` \ > -defsym checksum_rw=0x`cut -f2 -d' ' $(CHECKSUM)` > chmod 755 $@ > > Das starten von grub aus: > title L4 fiasco x586 l4v2 L4Linux > kernel /l4-20030315-x586/rmgr -sigma0 > module /l4-20030315-x586/fiasco.400000 > module /l4-20030315-x586/sigma0 > module /l4-20030315-x586/glinux root=/dev/hda2 > > Der glinux startet dann auch, und ganz zum Schluß : > > Warning: unable to open an initial console > Root: ptc is NULL for 00080030 (virt 00080030) > and pdir 00400000 at eip: 0050c11b > > Die Warnung kommt aus dem l4linux als ein open("/dev/console/") schief > geht. (offenbar ging wohl das mounten von / nicht :-() > > Was will mir der rest sagen ? pdir sieht ganz so aus wie die > Start-Adresse von Fiasco ? > > Was habe ich nur falsch gemacht ? > > Gruß > Rudolf Weber

1 0

RE: enabling/disabling trampoline
by Volkmar Uhlig 15 Mar '03

15 Mar '03

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.

7 8

enabling/disabling trampoline
by Cristiano Ligieri Pereira 13 Mar '03

13 Mar '03

Hi all, I understand that the trampoline mechanism slows down the execution because it adds one more level of "indirection" when handling system calls on l4-linux. I would like to run some experiments with/without it but I'm not quite sure on how to achieve it,i.e., disable and enable it back again. Do I have to recompile the whole kernel? Do I have to recompile only the Linux application I will run on the top of l4-linux? What exactly do I have to do? I'm pasting part of a message from mailing list in which Frank Mehnert mention something about a patch, which I could not find. Any help is appreciated. Thanks, Cristiano. > Additional speedup for L4Linux could be achieved by patching the > syscalls in the libc by direct jumping into the emulib of the process > preventing the trampoline mechanism (int 0x80 => general protection => > int 0x30 => l4linux server). I don't know if such a patch if floating > around somewhere. See linux22/arch/l4/x86/emulib/int_entry.S, function > entry13. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira

5 10

a article about l4 vm
by Yu Neil 28 Feb '03

28 Feb '03

hello: where i can find the article: "L4's Recursive Virtual Memory Model, Design and Implementation Issues of a L4 V4 Mapping Database" ? there is no link at www.l4ka.org Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

1 0

(no subject)
by Yu Neil 24 Feb '03

24 Feb '03

hello: where i can find the ChacmOS , the old link http://l4ka.sourceforge.net/download/ChacmOS-src-RC1.tgz is unavailable, thanks a lot Neil Yu _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

2 1

RMGR Documentation needed
by Daniel Koch 24 Feb '03

24 Feb '03

Hello Is there any good Documentation on RMGR available ? I need to know how I can load modules into specific areas of memory, because I got some overlapping module problems, almost the same as mentioned in the list before. The solution with l4ka GRUB using the feature modaddr doesn`t work for me, cause I use a different architecture (Athlon K7, Reiserfs). RMGR: loading (hd 2,0)/sigma0 RMGR: loading kernel (hd 2,0)/main -nokdb RMGR:overlaps:00300000 - 0030239c: (hd 2,0)/main -nokdb RMGR: 00100000 - 001be980 module 02 : 00231000 - 0023256c: (hd 2,0)/rmgr.cfg.linux module 03: 0023200 - 0032eb14: (hd 2,0)/glinux.gz root=/dev/sda3 overlaps = 1, mem_high = 0x0fff0000 RMGR: overlapping modules #!rmgr ### this is an example RMGR config file ### first, some global settings # small address spaces have a size of 64 MB small_space_size 0x04000000 # wait for key press after initialization bootwait ### configuration for Sigma0 and RMGR follows # NOTE: it's generally useless to specify any resource allocation # constraints for Sigma0 and RMGR here: most will be ignored because # these tasks statically allocate all of their resources. That's why # we only specify bootstrap parameters here. task sigma0 boot_priority 100 task rmgr boot_priority 100 # enable next line if you want RMGR to run in small address space # 3 #boot_small 3 ### configuration for boot modules follows task modname "glinux" # make sure this entry # corresponds to a Linux server boot_small 2 # small address space # 2 boot_priority 100 boot_mcp 0x90 # maximum controlled priority log_mcp 0x90 # logical maximum controlled priority # -- useful if "boot_mcp 0" child max 512 in [10, 1023] # at most 512 child tasks in that range memory in [0, 0x02000000] # use only lower 32 MB RAM high_memory in [0xc0000000, 0xffffffff] # use only hi memory in that range small in [1,3] # allow these small address # spaces to be allocated # enable next line if you want to disallow allocation if IRQs 3 and 4 # (IRQs for serial lines COM2 and COM1) # irq mask 0xffffffe7 end menu.1st: gfxmenu (hd2,0)/message color white/blue black/light-gray default 0 timeout 8 title linux kernel (hd2,0)/vmlinuz root=/dev/sda3 vga=791 initrd (hd2,0)/initrd title Linux other root (hd1,0) makeactive chainloader +1 title floppy root chainloader +1 title failsafe kernel (hd2,0)/vmlinuz.shipped root=/dev/sda3 ide=nodma apm=off acpi=off vga=normal nosmp maxcpus=0 disableapic 3 initrd (hd2,0)/initrd.shipped title Fiasco + "hello world" root (hd2,0) kernel (hd2,0)/rmgr-fiasco -sigma0 module (hd2,0)/main-fiasco -nokdb module (hd2,0)/sigma0-fiasco #module (hd2,0)/glinux root=/dev/sda3 module (hd2,0)/hello-fiasco title L4-Linux #root (hd2,0) kernel (hd2,0)/rmgr -configfile -sigma0 module (hd2,0)/main -nokdb #modaddr=0x03000000 module (hd2,0)/sigma0 module (hd2,0)/rmgr.cfg.linux module (hd2,0)/glinux root=/dev/sda3 no-scroll module (hd2,0)/hello -- ------------------------------------------------------------------------------------ "Schlage die Trommel und fürchte dich nicht" (Heinrich Heine) Daniel Koch Berlin

4 5

Ada run-time
by Nicholas Hannah 19 Feb '03

19 Feb '03

Hello, Is anyone interested in having the Ada run-time library running on L4? Has any work been done on this? I would consider contributing to an effort to get the core language going if there were others interested. I imagine it would be especially useful running on the StrongARM port of L4 for embedded systems development. chao, Nicholas

3 2

Re: Deterministic scheduling with local APIC
by Jacob Gorm Hansen 05 Feb '03

05 Feb '03

On Wed, Feb 05, 2003 at 09:09:35AM -0800, Uwe Dannowski wrote: > If you want to account time, then why are you interested in counting > instructions executed? I believe the number of instructions is more or less > irrelevant (unless you want to schedule other resources than just time). > > You can use the IA-32 processors' performance counters to enforce an > interrupt (or an NMI) after a certain number of events, be it cycles, > instructions, memory accesses, FPU ops ... If you care just about user > time, you can configure them to count only when executing in user mode. This sounds perfect, I need to control exactly how many instructions a thread gets per time slice, no matter how many interrupts arrive at the CPU in the mean time, so that scheduling becomes deterministic. If a thread is interrupted by a hardware interrupt after fx half its time slice, I need to know exactly how many instructions it has already run, and need to be able to grant it exactly what is missing after the interrupt has been processed by the kernel. If I can do this I should be able to guarantee that two user programs running on two machines, receiving the exact same input, will be in the exact same state at the same (logical) point in time. That means one will be able to take over from another in case of failure. It seems to me one could augment one of the IA32 L4 implementations with this functionality, connect two machines with some kind of FIFO link, a good hub which sends all packets to both of them, and have failover solved at full speed, without need to rewrite any user level software. Maybe this has already been done though. But as always the use of a microkernel seems to make things simpler. > Uwe best, Jacob

1 0

RE: Deterministic scheduling with local APIC
by Jacob Gorm Hansen 05 Feb '03

05 Feb '03

On Mon, 2003-01-13 at 16:06, Josh English wrote: > Jacob, Josh, I hope you don't mind me CCing this to the L4 list. > The largest problem I see with this scheme is that I cannot > conceive of a mechanism where the data sent to the CPU and > the failover CPU will not cause enormous delays. This is > because any failover system will require a confirmation of > the data received by the backup CPU. Even if the transport > and confirmation mechanism was hardware, the bottleneck > inherent in the design would render the system unfeasible in > a real-world implementation. I imagine that if the system is only ever accessed from the network, all the data that is to be duplicated comes from there. I suppose one could just use an Ethernet hub or similar hardware to make sure all Ethernet frames arrive at both hosts, coupled with a dedicated low-latency link between the hosts used for syncronisation (which given certain guarantees about the performance of the local Ethernet segment could be as simple as just each host counting all incoming frames and sharing the counter via the dedicated link). > Since my understanding of deterministic scheduling is that > in multiplicity scheduling, jobs are partitioned into > job types where the jobs in each type are identical. Then > the job is sent to any given machine as determined by the > scheduling mechanism. Thus sending every job to every > machine would cause much greater overhead than is justified > by having a failover mechanism. What I meant by 'deterministic' is just that all threads always get their full time slice. For this to happen a means of determining upon the arrival of an interrupt exactly how many cycles the running thread has left of its slice, and a means of granting it precisely this number of cycles before it gets preempted, is needed. I suppose you could use the TSC for the former and perhaps the local APIC for the latter, but I am unsure if trying to do so would be crazy. > Well, unless you are building systems to withstand nuclear > attack or something. So, if you want to write the code, I > think that your system would work provided your 'master' > scheduling mechanism resides above the kernel scheduler. > I think that this would prevent race conditions from > forming becuase hardware delays would be invisible to the > kernel at that point. I don't know if I will ever find time to write something like this, even if it were possible, but it struck me as an interesting future project. best, Jacob

2 2

Re: Ada run-time
by Frederic BOYER 05 Feb '03

05 Feb '03

Hello Nicholas. I haved. In the past, I start the development of an QNX like OS on top of L4 written in Ada. All the servers were written in Ada (but used the pragma NO_RUN_TIME) The most difficult is to write the GNART (or GNULLI don't remember) of the GNAT compiler to directly use the L4 thread and memory managment. This project is in stand by for me. The main pb is that my HD which hosted the projects crash and I didn't do save :-( Give me news. Bye bye. Frédéric. Nicholas Hannah <nhannah(a)cse.unsw.edu.au>@os.inf.tu-dresden.de on 05/02/2003 07:25:24 Sent by: l4-hackers-admin(a)os.inf.tu-dresden.de To: l4-hackers(a)os.inf.tu-dresden.de cc: (bcc: Frederic BOYER/PARIS/CAI-Cheuvreux) Subject: Ada run-time Hello, Is anyone interested in having the Ada run-time library running on L4? Has any work been done on this? I would consider contributing to an effort to get the core language going if there were others interested. I imagine it would be especially useful running on the StrongARM port of L4 for embedded systems development. chao, Nicholas _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Crédit Agricole Indosuez Cheuvreux except where provided for in a written agreement. Crédit Agricole Indosuez Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Crédit Agricole Indosuez Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein."

1 0

Fiasco compiling problems
by Manel Jimenez 29 Jan '03

29 Jan '03

Hi!I'm trying to build fiasco kernel but i've run in some troubles. After "make hello" it gives mes this error: ../../../../../lib/x86_586/l4v2/libl4dbg.a(i386-stub.o)(.text+0xac3): In function `getpacket': /home/juan/os/l4/pkg/l4dbg/lib/src/OBJ-x86_586-l4v2/../i386-stub.c:526: undefined reference to `strlen' collect2: ld returned 1 exit status In this file(i386-stub.c) "#include <string.h>" was commented, so i uncommented but the problem still persists.What am I doing wrong?Has anybody got this problem? Thanks in advance __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

User space scheduling, 2nd try
by Robert Kaiser 24 Jan '03

24 Jan '03

Hi I am currently pondering about ways to implement time partitioning in an L4 context, i.e. the idea is to distribute processing time to subsystems (consisting of groups of tasks/threads) according to predefined rules. Ideally, the underlying subsystems should be unaware of this process. Also, ideally, the concept should be recursive (i.e. a subsystem task should be able to donate (some of) its processing time to other sub-subsytems). At first glance, the concept of external preempters, as specified (though AFAIK never implemented) in L4 looks like it could be a useable basis for this, however: - I'm still having difficulties to fully understand preempters in L4. Their specification in the reference manual is somewhat sketchy. - I have a few ideas of my own, but implementing them would require extensions to some L4 functions. My past experience with the L4 reference manual has been that everything in there is there for a good reason, but the reasoning is not always explained (which is probably the way a "reference manual" should be). I would very much appreciate if someone could point me to a document that explains the reasoning behind preempters, as defined in L4. Failing that, are there any publications on external schedulers in the context of microkernels that might be helpful to read, any discussion forums you might suggest? .. or am I really on uncharted ground here? Any response would be greatly appreciated Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO AG Am Pfaffenstein 14 phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

2 2

User space scheduling
by Robert Kaiser 21 Jan '03

21 Jan '03

Hi experts, I am trying to identify (and examine) ways to implement user-level scheduling on L4. I read in Michael Hohmuth's diploma thesis on L4Linux that it would have been desirable to use the preemption handlers to implement Linux's scheduling policy, but since L4 did not support them at the time, he used L4's built-in scheduler instead. Also I read a posting by Gernot Heiser in the mail archive of this list in which he suggests that the preemption handler concept is somehow flawed. To my knowledge, none of the current L4 variants has implemented the concept. To be honest, I'm having difficulty to fully understand the concept. For instance, the difference between an internal and an external preempter is not clear to me. So my questions are: - is there any further reading (besides the L4 Reference Manual and the L4 User Manual) that describes the concept ? - has the concept actually been put to the test ? - roughly, how would I implement a specific scheduling policy in e.g. L4Linux based on this concept (assuming L4 does provide it) ? Thanks in advance for any insights! Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO AG Am Pfaffenstein 14 phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

1 0

Deterministic scheduling with local APIC
by Jacob Gorm Hansen 13 Jan '03

13 Jan '03

hi again, [OT: First of all a great thanks to everyone at TU Dresden for the interesting discussions and pleasant company during our visit last week.] Following a discussion with Jan Glauber Friday evening on the HP Somersault API, which does failover by making sure processes on a standby machine receive the exact same inputs as those on the master machine, I wondered if anyone knows if the PentiumII local APIC is precise enough that you can do completely deterministic scheduling, say, in Fiasco? It seems to me that one could implement an OS-level failover system by wrapping the OS in an I/O environment (like NomadBIOS ;-)) which would somehow ensure that the exact same input was received at both the master and the slave hosts, provided that the scheduling performed by the kernel scheduler could be performed with clockcycle precision (otherwise race conditions would allow things to get out of sync). Does anyone have an opinion as to whether or not this might be possible using current Intel hardware? best, Jacob

1 0

looking for PCA-200E firmware&driver
by uaca＠alumni.uv.es 09 Jan '03

09 Jan '03

Hi I'm interested in download the source of the Fore-PCA200 firmware the DROPs project made (source code), and also the driver I haven't found that on the guest access to the cvs server, etc... I have tried to contact Uwe Dannowski and other L4-ATM people with no luck anybody can help me? Thanks in advance Ulisses Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso ---> Visita http://www.valux.org/ para saber acerca de la <--- ---> Asociación Valenciana de Usuarios de Linux <---

3 3

how current l4(with oskit) implement the driver framework?
by Yu Neil 07 Jan '03

07 Jan '03

hello: how current l4(with oskit) implement the driver framework? ( the oskit`s ? ), and where is the Omega0 server ? ( not implement ? ) Neil Yu _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

1 0

starting
by Luis Araujo 27 Dec '02

27 Dec '02

Hi.... is there exist some good start-manual for the L4? i got the L4refx86, and im looking for more concepts......... thanks _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com

1 0

is there any l4 lib avaliable ?
by Yu Neil 02 Dec '02

02 Dec '02

just like the l4 environment from tu-dresden, but it`s unavaliable Neil Yu _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com

2 1

RE: L4 on iPAQ question
by Volkmar Uhlig 15 Nov '02

15 Nov '02

> -----Original Message----- > From: Christian Stüble [mailto:stueble@cs.uni-sb.de] > Sent: Friday, November 08, 2002 5:01 PM > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: L4 on iPAQ question > > we just got some iPAQ 3870 Handhelds (very nice > little devices :-) and I will try to port PERSEUS > to it. Obviously, I should start with installing > L4 onto it. But I don't know more than that I > have installed the bootldr Bootloader that can > boot images from Serial or CF (installing plain > linux works well). Has someone else tried to > install L4 on iPAQ and can give me hints > how to do it? If not, what should I do first? > What should I read? Christian, the current version of Hazelnut supposedly works on the iPaq. I used it on the one I have here which is a 3630 model with 32MB RAM. You explicitly load the arm-booter image to address 0xC1000000 and then jump to this address. It loads the elf images and starts the kernel. Currently, the kernel supports serial line as debug output device. But be aware that there are unsolved issues like IRQ handling. > Next, L4Linux has to be ported to the StrongARM. > Is there a L4Linux/ARM available somewhere? Is > someone working on it or has a student that can > do it? AFAIK, there is no L4Linux port to ARM. I did a not-yet-released port of Linux 2.4 to L4 for x86 which currently runs on Pistachio, Hazelnut and thanks to Adam on FIASCO. Based on that you could start an ARM adaptation. Adam started to factor out the x86 and L4 API dependencies to make the code base more reusable, but the x86 dependencies are still tremendous. The former port of L4Linux to MIPS started a completely new Linux hardware architecture. Thus, I do not have a clear idea how much architecture dependencies will show up, but I expect a lot. I mean a lot!!! I do not know anybody who currently plans to do an ARM port nor do we have any resources to do it. Maybe the Dresden group??? - Volkmar

2 1

L4 on iPAQ question
by Christian Stüble 08 Nov '02

08 Nov '02

Hello, we just got some iPAQ 3870 Handhelds (very nice little devices :-) and I will try to port PERSEUS to it. Obviously, I should start with installing L4 onto it. But I don't know more than that I have installed the bootldr Bootloader that can boot images from Serial or CF (installing plain linux works well). Has someone else tried to install L4 on iPAQ and can give me hints how to do it? If not, what should I do first? What should I read? Next, L4Linux has to be ported to the StrongARM. Is there a L4Linux/ARM available somewhere? Is someone working on it or has a student that can do it? I can try to do so, but I fear here in Saarbruecken it is difficult to find students with experiences in Linux, C and OS in general. Maybe, I have to do it myself, but I will need help from the DROPS and L4KA people... Thanks & Regards, Chris -- Christian Stueble <stueble(a)cs.uni-sb.de> Saarland University, Dept. for Computer Science Security and Cryptography Group @Saarland University/DFKI Im Stadtwald, D-66123 Saarbruecken, Building 45, Room 534 Tel.: +49(681)302-5635 Fax.: +49(681)302 4631 Get public key from http://www-krypt.cs.uni-sb.de Fingerprint 8678 C5D3 CAD9 CD8C F1DD B8EC 202F 116A

1 0

NomadBIOS source availability
by Asger Henriksen 05 Nov '02

05 Nov '02

Hi all, Just wanted to let you know, that a read-only cvs repository has been set up for access to the sourcecode for nomadbios. It is still a little rough, but we will iron out whatever issues can/will arise. The cvs repo contains the source for the linux22 sourcetree, as well as the nomadbios server itself. In the download area of the website patches for Oskit and Fiasco has been added. Just do cvs -d:pserver:anonymous@udenbysvester.dk:/var/lib/cvs login <no password> cvs -d:pserver:anonymous@udenbysvester.dk:/var/lib/cvs co <module> where module is either linux22 or nomadbios. If you check out linux22 you must use the "guest" branch when checking out, otherwise nothing will work. Regards, Asger Henriksen

1 0

NomadBios sources now available
by Jacob Gorm Hansen 05 Nov '02

05 Nov '02

not pretty, but there. I've also put up our experimental fiasco & oskit patches. best, Jacob

1 0

NomadBIOS project
by Jacob Gorm Hansen 02 Nov '02

02 Nov '02

hi all, we have just put up a minimal website about our thesis project, titled 'NomadBIOS', which allows you to run multiple l4linuxes at once, and to hot-migrate them between host machines. The thesis is not exacly written yet, but in the meanwhile you might want to have a go at it. The website and download is at http://www.nomadbios.dk Have fun! Asger Henriksen & Jacob Gorm Hansen

1 0

RE: Re[8]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

> As far as I understand you want to find out whether: > - mklinux is really as bad as published > - L4Linux is really as fast as published > > Start with the first one. > > Then fetch a version of L4 from l4kabuild l4linux 2.0 against it and > try to find out about the second point. (I don't know whether l4ka's > version supports 4Mb pages and small address spaces but you will find > out whether they do or not) Hazelnut supports small spaces. We published a TR about the performance of small spaces for the P4 architecture using an L4Linux environment. See also: http://i30www.ira.uka.de/research/publications/ Actually, the relative syscall overhead using an adopted glibc was lower than the original numbers given by the SOSP paper. We ran L4Linux and the applications in small spaces. (Hazelnut supports different configurations for small spaces -- up to 2GB for the small space area.) - Volkmar

1 0

Re[4]: performance of L4Linux
by Igor Shmukler 29 Oct '02

29 Oct '02

> Well, then you should probably start reading the publications about L3 > and L4 of the last 7 years and you will find an in-detail analysis why > your statement could be taken as offensive rant... ;-) There are pretty > exact numbers of MACH's cache utilization and performance of IPC and the > structural problems of the communication mechanism. Well, I have done that (read papers). Cache utilization is very easy to fix. In fact when I did Mach VM overhauling (couple of years ago) it maybe took me one day to implement coloring. IPC issue was not discovered by l3/4 team, but rather was known issue for very long time. There are much older Utah and UW papers that address that. Anything else l3/4 team has up the sleeve? If I was to say that being tightly architectutre coupled is strange or that since l4 took almost everything out of the kernel, memory management could have been evicted as well (like eros microkernel does), then you may need to get offended. Otherwise, I don't see your point. L4 papers states that since there is no way to prove that Mach only causes 5% degradation statement is not valid. I say same logic applies to MkLinux vs. L4Linux. I am not trying to start am flame war. Nor do I claim that L4 is worthless. I simply want to see if there is a way to validate specific statement. If there is, that means that statement is valid, if there is not, then you tell me ... As simple as that. IS.

2 5

RE: Re[6]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

Just out of curiosity -- where do you want to get the not publicly available L4 x86-assembly kernel from to actually being able to redo the measurements? It is intellectual property of a company and not downloadable anywhere. Furthermore, if you redo the measurements on different hardware and you read the "On mk construction" paper you should know that MKs (at least L4 MKs) are highly optimized for one particular architecture. Hence, even when having the kernel and running it on different hardware your numbers are bogus and do not state anything except that you get a set of more numbers...

3 2

RE: Re[8]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

> > Just out of curiosity -- where do you want to get the not publicly > > available L4 x86-assembly kernel from to actually being > able to redo the > > measurements? It is intellectual property of a company and not > > downloadable anywhere. > I think I already have it. Otherwise, I'll make sure to contact you personally. Which won't help since I don't have it. So I'm surprised that you have an instance. > Well, I was under imperssion that L4 is highly optimized for > a processor (CPU), but not an PCI2ISA bridge or hard drive bandwidth. > Am I missing something? Please let me know, so that I don't > waste my time. So if you have a Pentium 1 and the kernel you should be fine. - Volkmar

1 0

performance of L4Linux
by Igor Shmukler 28 Oct '02

28 Oct '02

I read paper comparing performance of L4Linux of MkLinux (atop OSFMK) on x86 computer. Results are very interesting. I would really like to conduct benchmarks on my own. I know where to download Linux and L4Linux, but not the MkLinux for Intel. Does anyone still have binaries? If you do, please let me know how I could get these. Thank you, IS.

4 8

Local IPC identifier
by Jacob Gorm Hansen 25 Oct '02

25 Oct '02

hi, For some purposes when sending ipc to other threads in my task space, I find the need to explicitly state a taskid problematic. This information is redundant, and redundancy _always_ leads to problems. For me, the problem occurs when I move the l4linux server to a new task number, and another l4linux runs with my old number. All my threads get confused, and there is little I can do to help them (not without C&C at least, but that would still force me to use a taller task hierachy than I would like). What I need is something like 'if partner.id.task==0 then partner.id.task=current.id.task' in the kernel, and I suppose I will make such a hack myself. Is this what the rumoured 'lipc' feature in Pistachio is all about? Or is such a feature already present? thanks, Jacob

3 3

Lack of C&C redirection?
by Jacob Gorm Hansen 24 Oct '02

24 Oct '02

Hi, the Fiasco website says that nobody ever implemented C&C redirection for L4. Is this planned? What will happen in the current version, if I try to ipc to a task outside my clan? Best, Jacob

3 4

crt0.S and C++
by Alexey Mandrookin 15 Oct '02

15 Oct '02

Hi, Could anybody help me with crt0.S? I have project, which tightly related to L4. Project written in C++ and use abstract classes. The crt0.S was taken from FIASCO L4 examples and works well with C code. Unfortunately, it does not work with C++ code. Calling constructors for global objects does not work. Program crashed when abstract classes or virtual functions are used. It seems, virtual tables is not initialized. Guess a __static_initialization_and_destruction_0 function was not called. Does anybody have a C++ compatible crt0.S? Alexei

2 1

Native OS
by Alexey Mandrookin 09 Oct '02

09 Oct '02

Hi, does anybody interested in native OS implementation on top of a L4 microkernel? Perhaps I can donate a console driver within October. Alexei

5 7

Re: Native OS
by Frederic BOYER 09 Oct '02

09 Oct '02

I am interessed by a such project. In the past, I planed to write an Unix like on top of L4 in Ada. The goal was to port the GNAT Ada Run-Time on top of L4 and then write all the servers needed to make a good O.S. My new job take me a LOT of time, but I plan to realise this a futur day. Regards, Frédéric. "Alexey Mandrookin" <alman(a)mgateinc.com>@os.inf.tu-dresden.de on 09/10/2002 04:38:26 Sent by: l4-hackers-admin(a)os.inf.tu-dresden.de To: <l4-hackers(a)os.inf.tu-dresden.de> cc: (bcc: Frederic BOYER/PARIS/CAI-Cheuvreux) Subject: Native OS Hi, does anybody interested in native OS implementation on top of a L4 microkernel? Perhaps I can donate a console driver within October. Alexei _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Crédit Agricole Indosuez Cheuvreux except where provided for in a written agreement. Crédit Agricole Indosuez Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Crédit Agricole Indosuez Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein."

1 0

Pistachio
by Thomas Quintana 07 Oct '02

07 Oct '02

Hi, I was wondering what the time frame for the Pistachio micro-kernel looks like cuz i'm really interested in working on a multiserver project (ex. sawmill) under the v. 4 spec. the performance gains should be outstanding and good enough to compete against most monolithic kernels (not that the hazelnut kernel doesn't give them a run for their money). If any help is needed in the development pls post cvs and a todo list. thx, Thomas --------------------------------- Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com

1 0

Purpose of ping-pong in l4linux
by Jacob Gorm Hansen 02 Oct '02

02 Oct '02

hi, what is the purpose of the ping-pong task in l4linux? I can see that it handles vmalloc requests for the kernel, but why does it need its own task for this? thanks, Jacob

3 7

Tuning L4Linux on Fiasco
by Jacob Gorm Hansen 01 Oct '02

01 Oct '02

hi, the original l4linux papers mention performance about 4% lower than native linux. When running l4linux on top of Fiasco, performance seems to be more like 50% of what we get with native 2.2. For example, encoding a .wav-file to ogg-vorbis takes 2 minutes native, and almost 4 minutes with l4linux. LMBench also gives way-different figures. Is there anything we can do to tune Fiasco for better performance? Are other people experiencing the same speed differences as we are? Best regards, Jacob

2 3

Bugreport
by Alexey Mandrookin 24 Sep '02

24 Sep '02

Hi! I found strange behaviour of l4_i386_ipc_wait(). In case of interrupt IPC, it return wrong value of the thread id of IPC source. *** Version $gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) $as -v GNU assembler version 2.11 (i686-pc-linux-gnu) using BFD version 2.11 $ld -v GNU ld version 2.11 (with BFD 2.11) *** UUencoded source code begin 644 test.tar.gz M'XL(`-=5CCT``^U:67/;1A+V*Z;*_V%B20XIDR!(4Y:+BE/10<M:4\>*<C;> MV(L"@:&("`<#@#KBTO[V_7IP\U!<J;6=![1*)&:FIZ>[IZ>/`<T@TM3AHR\* M6EO37G2[CS1-:V]O:<5O@N?MYYU'VO96]WFWLZUUM@A_^_F+1US[LFS%,`LC M(^#\D2-NC8?Q1!!^#8:^+JQ98FQ[@NOZ[G#8/]X;O-=UMF9[IC.S!/_!Z;9, MWYW:C@C4R8],88H:B=N(L?[)Q?G[FJZ;0:1;,]>]T_5ZVDD:C=)6TE`<83@* M&N958T.$4Z:8AN,HP_?'>Z<#_63WN%]S#=L#8B`*Y).^UB;?!SJG_TO''QD. M-WTOC(*9&?E!J'*^V9)+*+*-%4:WK-U37/_:46K4JJ//N&6*'S@*/27-W_Y0 M.N.$E\VXR[`L1UGOQC24W]RITAZQ3B_FBR<`AHYG3F3O^7[$)\*P1,";/!2" MN]0]0K<ZB=E:L\?0,13<'[R&;E,*JN'8EQ[G7;8FG%`0Q>]2I`:/)D;$76%X MW%#]6<2-,!3N"+M`%.=)=$#"L^QQIC9WI,<\U7-<Q_<N\:W=MO=V#_8TK<-+ M@.5=X](V2_2S.71BZ:@NS!D[QF78X[NG[R[TMX-W!X?]902:11+-`@\+F$5[ M*(A!2\6/.K8G6+9&:6;)+&FRXQO6RJFZL(S(4!0E180V'T#VK!AU%(8/8I8X MBH\!31->%-Q)>\5A`@V&KW!JF$)I:YTNDT>DQQ@P_S41V'_O+C7Y:R.P#1@! M]X2P;*QA%$\!MT-N"=,Q`F%QV^/[SYXU&-_D=L1O`CL2(=")LQL_H/'(AY$) M_KTJ3\SWL%TSLGV/9MQ,;'-"Y`P^]8$)JTNPC>DT\*?@(A*EI0/8*'D1H-%1 M4IF43TUH\GB-QA/C2>,G$+@<V5'X-S]*K4WEK+,[.#H\J77JL32D/*799E(8 MN4.DK*'MVM"Y<]=8JL]8C8X=1MP?I^H,:2)T98EY#89\C$:RW]A![H]^`Z%P M0:/6$HW^/=1C)>KYUI&M@L^!8^,*"8`CON0:?Y+_=31M.\W_D/A1_M?N:L^K M_.]KP!IG:WS]R.KQU!(:U[RM=CAVI=/2VJWG;=[N]MHO>EO;?.)/W%DTX?W; M*5]G:YB93I)N"QITIWAV$;/T:!+`ER,W,/&-<$&I6[OSDB?]B&L6+?T9X`AX M);BH,#0N$7;N3$=@;<P-37@M<KJ#;B$K'-N7L\"07I(X8_98_,YKZY\&7?W@ MZ/R^03G1H(M'_HJK:LOI,O**A<X,E<6^+DV&UVL2H]XBH6FA$(a)^.;RY=G]MC M"L'B%B$@!#->RLW1R?!B=S`H\*0G77K.1P$IX88U4WY2-E2Y-'*2-4ZJ19`) M0YO2A+/SHY]W+_I$;DB\"N_:#GP7"0C;?SW8/1SR9Z^4YBG;/SM+F\C5C@_8 M6G-L3H1YU?3$#6/#\WT=*/R5HB"+B%1S.HT[A]1ER@*2L<'1GFPW'=?D3<</ MK^Q(#V?3J1]$:#NNB\\K$7CX"MS+@+&+W?/#_@7F$%7PMPS`-4*:@40`5G4% M*XJ3%`9KZO%X'GWVUFNG>_\8HE+`)AW4>?.$-R^H4$&NV='BM-/GZS_Q]?_( M;20E@V':36J#=3DUT7:=,)LA;[I\>VLKW_>1[;78:G-0P\B"+[D4V&<JH>!8 MP"6*D,)Q8&O),OIQ?SC</>S7LQZY<-.2=(N6D*Q;0BN27#6!)>;@^M8,QF") M*0Q(>*8MPMR&UFL'_3,(_ZW=4`7?"-(3_277>#C^M[O;VE82_[<Z+]IQ_.]J M5?S_&H`B1F;Y1V?[TI\B@EE"96T47$Y7MY^_?*';4U._,>RH5N<H-1!87#B3 M"(6(L%0Y]P+A3]8UP6P:24H(?$X8A\5NXJ=L2X]X7.[,`L%O;.01:!H>8OJU MX<Q0^M0T5>/((]J::L0W%V_\&W$M@@8(!N`M7\3T72J`)97("*^X;2%B:LA; M:E?B;N0;<8T;8]<9ZT">_<*-4;',BDLL#@ZYAQ*4"EAA,;;98H6+,,S$@NKD MQ\>E3LOV%_L<>R0['Y<OTL*[D/Z)?DB7:0N#4/1"/X7*%@C2MSII%4?'SNRV MY1KF!'5C:[K`B!R^??FB-3)"H5^[\7!RW8=*CP+SJ.8UKNL*6B-]*I]S%-M+ M,.J*[<GANA0I&3X[/;_0W^X=Z`>[%[L/9&_:[0MMR2Q$JXMWPX=FM?-91^?_ MU&DF<AR%`CKQ87L.#5W[V#:9=06NGNUXC;K![J?'3,E$S<@T9%90WWG,[HE2 MOL[;_ON]T]WS`WWOW>O7_7-]>/3O?I&K6ON''U[65^,?[P[?EO"7$6RVI1[E M]8EBT6V,'D&NDU-]_\WNR6%?45XIM:0?"4%[A\6X9,\\7Q+"P.(Q&(a)_.O!`5 MNH`N)G!G)"DQHZ?H=#ANM<Y.D12V8/]M+",(:9TN5F*F8X0A#XP;G<X1_\2F MLY%CFSVFI'VQ;G>80D04?"+/2\]<<M8SE(PKX"I(C`@Q'633P+Y&90#2U`,5 MX&#X-SDM._@]Q86/CFR3)WA%C+D5RXC36:2/9N/QW"BI"*/$SY)18E510KK9 M(VY+#JRAH.F&EY8_%7!GF_FLD>]3"FZ'DJ0(=,_W=.%.HSNXS4_(Q.#U/%XC MM#H'7=WT9UZTP^\+>BB1(H^KPTL1$SNLQ`66D8*7629A;61XM[#K8C^).==_ M[3OX=J375G)FLO&2,24(E@A__9BCQ$Q2Q-"G=&5D[;![[&G<G9I*KU>4`E8V M-E!J[3#)5XZ4<4Y6^GAA.!.`AL%!B?L<+9-#HK&R#/-H),VRPTD22B%X/J,@ M9"X"R\>S@X&-EE$+\H2U)T=C?N?/Y$5F-+'#M(!ME-Y<+,:AD./H7X5/8%I$ MJ[PXIF%MV(QT>SD+JTX.BQDJ.P<R'A<Q<R>._&D3Y%.7#_?83M;/1I^^XO]= M<"LQ3N9A:5XCFU)?QFGY2((_)1"7*(U%,,=E!N:$]D0Q)P4&2\&'''G!2#-K M^H@)<G)^-)X]*S5)J&4^/"<(<XKG+(88&3_@,(G9LK'^=?DT<JOC6K8V6902 M#^4"9N>!C+5POF-&\_9#TN7B-9O4OI?OW<A%@1T2BYQ[+E7F#9DRYXGH"MOV MY'5'@Y6\H[()DB$J=ZF%\G%4XGVA14BFG53^3'L4/&@$?<4TE/BH%9>4MR9G M^_KP#5G$\?"PP?/8J14;YB1#/NG_W#]O\(0[K+3<2V4:D1PNFO+*,$3RYH'] M!FS<($[/:\X5\JC@@P0+S!W.YQ28Z"\.M:`4,T(X:`=))$CMD73H0E]$X2X4 MCM1AID1*'W5I&7`-Q1Q"!O(QKTF\[V"!L<FU-F7V'LZF(KBV0SBIF/7D'DO> MWF$SZ&+.$Y?8BVM!^IS"M0GY.D!!5/.B<>W)1MC;L'H\UU&/GQ\?GJ.$\&Q* M#(+?^<:L)Y6,%&7C]H/WI`%%*(JNOSX:].D5A:X/CD[D4Y'SAIQ#_&-K*"*J MSD2%&^2ORDG2,TJ2TO&)?9F<,_E2F=[$13XWH@AI-#W1A$12DF*)"0;"%)"V M)K=NT?J>TG8_O6EG8Q='Q_W3=Q<UK4%_;?JL`R,SOK+ZDTGG_61:O!NI+HM* M-`WO>QS1U+F`=Q*1]X,`F[5&JM2ZOTAEQFKBL9X@='CGF9/`]^P_Y`L[>L%& M!,C)D\RN4&U+=1(MD*[XZK-(1OS91U";/X&Y%CAQ1L%$D2](P8\-?XO4DBY6 M_2F].Y,G!S4?#B`Y0^D+F4(<4PRM[>R0KM:@3/F6FBG_C\U;X%/)=BO>&26. M]<6-(8M.UH$G09YB81?DU'M62$G1(U_',=9J\=0'Y"8,"YWK+YKN,MEDB?XT MF0">,\_P=>1*3/0\QK"(<_6#]R$:^K/`%'SC5MVXY:CE0[H8CX]Y*AS,C:RO MV$[,K]B5S-6A'[EJNN*'Z`TTTQM`;3#Z7WKTP<^E8'SCE^(ZB1(;966G@4!- M'.\<\3,C,-RV),WE<R=^SN\BXD5X[.<;^0`Q38XZR:2D3>+XX9,:(QPN.''S M2KX(MBFD7<[L<,)'(KH1PN-TX20O4\C7EJY7U)1&`&DB?F/<T5MF^IV.$8AT MCZSL7D1>DFAJ)YGTSL-YB68(H,*YHU<3EB]">?-!B2>0I/M&%G*C\5=90)B/ MD7$FJDA$OKSJJ?,L;2`W432V>R[?1*>6EL?\>.'"4@\125]&XVDA8UE=EE)T M+A2"Z0LI^MG%KWE)_)$2$!K>E"-3JBJ>KL!%D?Z13F46\^4O3U*+6(C\)(=[ MIT\#09JBVRUJH30(=N82@'+\3S,E:*A4%20)B]RGSRP_'J@^2M8@S_>J,D3& MDV)^03JOK4@H_BP=H+ES6<"R!"`)^8@323!#3I,&["F=3D$_KTCB6.P@\VQ( M*6J=Q\'VY.?=P1$2A8-DF+9A<:BPA;JX11BY#*4Y9I<VI<>GY=U]FM+%8V(9 MY>\X"Y`:P=*NV$E;Y4!<S&J2_"5YMUK(6!;YC$G)G"H/Q4MRUSF,Q.QE[VJ! M:'"U3/)'95>41@90UI(UR6\%,\^CN#X2L$;YLR*XPAGUK,C`DD"7B/50%%\9 M[MBRNZ;$3[,D]KW-[Y'MR#8<I$N6/`_S94'QDFNN$LRNN^@,%`YQ[BJ*/F+) MP2][CD*E@*(%[AE3DZIQ58*V6DUIO%J9$OQYCO&7=)^Y`HIM:;!2>1)GD20D M438I!6(V"WJO%?5=E\J[SZ]C%+K6H(V@7XX6KH'3:KNT67`C22DJ;770+;YA M,")S`E\@M;#9HAL!=6E0J>\H"EWHIBM8/J=KY[BTI\)=32U!7E1(#YTZ0S-. MT"=RY)Y^>.>(&F;!;[9E7VJ,P\F,`O6-5[1`+;W!_M8OD2JHH((**JB@@@HJ JJ*"""BJHH((**JB@@@HJJ*"""BJHH((**JB@@@HJ^&;P/[=^;\8`4``` ` end Best regards Alexei

3 3

Portable servers?
by Alexey Mandrookin 20 Sep '02

20 Sep '02

Hi! How to write portable servers for L4 micro-kernel family? I found what the l4_threadid_t type is different in various L4 implementation. Does any wrapper on top of syscalls exist? ==== Fiasco microkernel: ==== typedef struct { unsigned version_low:10; unsigned lthread:7; unsigned task:11; unsigned version_high:4; unsigned site:17; unsigned chief:11; unsigned nest:4; } l4_threadid_struct_t; typedef union { l4_low_high_t lh; l4_threadid_struct_t id; } l4_threadid_t; typedef l4_threadid_t l4_taskid_t; === L4-KA microkernel: ==== #define L4_X0_VERSION_BITS 10 #define L4_X0_THREADID_BITS 6 #define L4_X0_TASKID_BITS 8 typedef union { struct { unsigned version : L4_X0_VERSION_BITS; unsigned thread : (L4_X0_THREADID_BITS + L4_X0_TASKID_BITS); unsigned chief : L4_X0_TASKID_BITS; } id; struct { unsigned version : L4_X0_VERSION_BITS; unsigned thread : L4_X0_THREADID_BITS; unsigned task : L4_X0_TASKID_BITS; unsigned chief : L4_X0_TASKID_BITS; } x0id; dword_t raw; } l4_threadid_t; ========================== Second question is how to distinguish between IRQ messages and ordinary messages. That code makes me confused: irq_th.lh.low = COM_IRQ + 1; irq_th.lh.high = 0; as I understand, it correspond to irq_th.id.version_low = COM_IRQ + 1; irq_th.id.lthread = 0; irq_th.id.task=0; irq_th.id.version_high=0; irq_th.id.site=0; irq_th.id.chief=0; irq_th.id.nest=0; Is lthread = 0 and task = 0 means interrupts? Third question is how to handle memory mapped IO? I found phystokv() function. It is just a simple macro, which placed deep inside of OSKIT Is that right to use that function for MMIO? What will happen if several servers requests same memory range simultaneously? Best regards Alexei

2 1

Clans&Chiefs question
by Jacob Gorm Hansen 16 Sep '02

16 Sep '02

hi, I have the following setup: - rmgr, fiasco, and sigma - a network server 'net' which exports an abstracted ethernet-device, built with oskit10. - a custom pager, 'pager' which is able to spawn new l4linux servers (currently piggybacked on to it). All started via entries in menu.lst, using Grub The spawned l4linuxes would like to talk to 'net' so that they may boot from NFS. However, net and pager are not in the same clan, so that is not allowed (obviously they need to talk to pager as well to get paged). Both net and pager need to talk to rmgr. Is there a way, other than merging net & pager into one task (which works fine, but is not really what I want), in which this can be made to work in fiasco? Thanks, Jacob

2 1

One more problem
by Alexey Mandrookin 13 Sep '02

13 Sep '02

Hi everybody! New problem appeared. It seems to be a make looking for subdirectories and did not found theirs. $gcc -v gcc version 2.95.3 20010315 (release) $make hello make[3]: Entering directory `/usr/src/Fiasco/l4/pkg/l4util/examples/watchdog' set -e ; for d in ; do \ make -C OBJ-$d all ; done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `set -e ; for d in ; do make -C OBJ-$d all ; done' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/Fiasco/l4/pkg/l4util/examples/watchdog' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/Fiasco/l4/pkg/l4util/examples' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/Fiasco/l4/pkg/l4util' make: *** [hello] Error 2 Best regards Alexei

2 2

Re: Two questions
by Udo A. Steinberg 13 Sep '02

13 Sep '02

On Fri, 13 Sep 2002 13:33:06 +0900 Alexey Mandrookin (AM) wrote: [ Please reply to the l4-hackers list instead of sending private emails! ] AM> I downloaded latest CVS version again. Now I compile under Red Hat Linux AM> release 7.1 AM> gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) AM> New problem appear: Note that gcc 2.96 is NOT an official gcc release by the gcc team. Redhat got a development CVS gcc snapshot and released it as gcc 2.96 in their distribution. The gcc team states that the object format used by 2.96 is not compatible with neither 2.95 nor 3.x. Eventually Redhat people got a clue and shipped a working compiler (kgcc). I strongly recommend to use gcc 2.95.x or gcc 3.x for building the L4 tree. Alternatively try compiling with kgcc instead of gcc. AM> It is look like gcc version incompatibles, so I fixed that problem by AM> changing 'short' type to 'int'. AM> Guess is Ok, because the stack alignment is 'int'. AM> Next, I start make hello agian and one more problem appear: AM> ld -N -Ttext 0x200000 -o hello main.o AM> ../../../../lib/crt0_getopt.o -L../../../../lib/x86_586/l4v2 -L../../../../l AM> ib/x86_586 -L../../../../lib -L../../../../../oskit/lib -L/home/drops/lib -l AM> mc -loskit_support -lmc -llmm -lkern -ll4util AM> ../../../../lib/x86_586/l4v2/libl4util.a(getopt2.o): In function `arg_init': AM> /home/alman/work/L4/l4/pkg/l4util/lib/src/OBJ-x86_586-l4v2/../getopt2.c:54: AM> undefined reference to `strlen' AM> /home/alman/work/L4/l4/pkg/l4util/lib/src/OBJ-x86_586-l4v2/../getopt2.c:54: AM> undefined reference to `strlen' This also works with gcc 2.95 and gcc 3.2. If you install a decent compiler you'll save yourself a lot of headaches. -Udo.

1 0

Re: Two questions
by Adam Lackorzynski 12 Sep '02

12 Sep '02

Hi Alexey! On Thu Sep 12, 2002 at 18:27:18 +0900, Alexey Mandrookin wrote: > could you explain, where is I should send my mail, into > maillist or personally to you? Please use the mailing list. Also consider subscribing (see http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers). > Latest CVS version complation problem: > > cd l4 > make hello > ---------------------Start > here ---------------------------------------------- > make[2]: Entering directory `/home/alman/work/L4/oskit/examples' > ld -Ttext 100000 -L../lib \ > -o fdev_test ../lib/multiboot.o fdev_test.o \ > -lfdev -lfdev_linux -lkern -lmc -llmm -lfdev -llmm \ > ../lib/crtn.o > ../lib/libfdev.a(buf.o): In function `fdev_default_buf_copyin': > /home/alman/work/L4/oskit/libfdev/buf.c:35: undefined reference to `memcpy' > ../lib/libfdev.a(buf.o): In function `fdev_default_buf_copyout': > /home/alman/work/L4/oskit/libfdev/buf.c:45: undefined reference to `memcpy' > make[2]: *** [fdev_test] Error 1 > make[2]: Leaving directory `/home/alman/work/L4/oskit/examples' > make[1]: *** [examples/all.MAKE] Error 2 > make[1]: Leaving directory `/home/alman/work/L4/oskit' > make: *** [oskit] Error 2 > -----------------End here--------------------------------------------------- > > I was try to fix that problem by myself, but another error appears in other > places. I have no problems using gcc version 2.95.4 20011002 (Debian prerelease) and GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux, I just tried it and it built successfully. > ---------------------Start > here ---------------------------------------------- > title Hello world > root (hd0,4) > module /boot/fiasco/main -nokdb > module /boot/fiasco/sigma0 > module /boot/fiasco/hello > > title L4Linux > root (hd0,4) > kernel /boot/fiasco/rmgr -configfile -sigma0 > modaddr=0x03000000 > module /boot/fiasco/main -nowait > module /boot/fiasco/sigma0 > module /boot/fiasco/rmgr.cfg > module /boot/fiasco/glinux root=/dev/hda5 > -----------------End here--------------------------------------------------- > > RMGR, which included in source tree: l4/pkg/rmgr/server/examples/rmgr.cfg > > ---------------------Start > here ---------------------------------------------- > #!rmgr > > ### this is an example RMGR config file > > ### first, some global settings > > # small address spaces have a size of 64 MB > small_space_size 0x04000000 > > # wait for key press after initialization > bootwait > > ### configuration for Sigma0 and RMGR follows > > # NOTE: it's generally useless to specify any resource allocation > # constraints for Sigma0 and RMGR here: most will be ignored because > # these tasks statically allocate all of their resources. That's why > # we only specify bootstrap parameters here. > > task sigma0 > boot_priority 100 > > task rmgr > boot_priority 100 > # enable next line if you want RMGR to run in small address space # 3 > #boot_small 3 > > ### configuration for boot modules follows > > task modname "glinux" # make sure this entry > # corresponds to a Linux server > boot_small 2 # small address space # 2 > boot_priority 100 > boot_mcp 0x90 # maximum controlled priority > log_mcp 0x90 # logical maximum controlled priority > # -- useful if "boot_mcp 0" > child max 512 in [10, 1023] # at most 512 child tasks in that range > memory in [0, 0x02000000] # use only lower 32 MB RAM > high_memory in [0xc0000000, 0xffffffff] # use only hi memory in that range > small in [1,3] # allow these small address > # spaces to be allocated > # enable next line if you want to disallow allocation if IRQs 3 and 4 > # (IRQs for serial lines COM2 and COM1) > #irq mask 0xffffffe7 > > end > -----------------End here--------------------------------------------------- > > Linux kernel compiled with default parameters, i.e. "L4Linux options" was > not changed > > The error message is: > > ---------------------Start > here ---------------------------------------------- > SIGMA0: Hello! > RMGR: Hi there! > RMGR: running on FIASCO > RMGR: total RAM size = 130623 KB (reported by bootloader) > received 103476 LB RAM from sigma0 > 460 KB reserver for RMGR > RMGR: received no IO ports > RMGR: attached irqs = [ <!0> 1 <!2> <!3> 4 5 6 7 <!8> 9 a b c d e f ] > RMGR: starting task /boot/fiasco/glinux root=/dev/hda5 from > 0x03065000-0x031897dc > to [ 0x003ff000-0x004f0458 0x004f2000-0x0053db74 ] > RMGR: starting task /boot/fiasco/glinux root=/dev/hda5 (#0x5) > at entry 0x3ff000 via trampoline page code 0x54168 > > RMGR: task 5.3 at 00516d4a is trying to get page 00000000 which is reserved > RDB: double page fault > > --double page fault------------------------------------------EIP: 00122c50 > (4.00) jdb: > -----------------End here--------------------------------------------------- Just try using some simple setup first, something like: title L4Linux kernel (nd)/tftpboot/adam/l4/rmgr -sigma0 task modname "glinux" module modaddr 0x005A0000 module (nd)/tftpboot/adam/l4/kernel -nowait -serial_esc -serial -comspeed 115200 -comport 1 -nokdb module (nd)/tftpboot/adam/l4/sigma0 module (nd)/tftpboot/adam/l4l-2.2/glinux no-scroll root=/dev/hda5 Adam -- Adam adam(a)os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 1

Two questions
by Alexey Mandrookin 11 Sep '02

11 Sep '02

Dear gentleman, I am sorry for disturb. First of all, what's happen with Fiasco microkernel? Latest CVS version does not compiles, but two week old version is work Ok. Guess it is because Fiasco migrating to the X.2 version API specification. Is it so? Next question is, why L4Linux does not start? After running L4Linux, the microkernel complain with double page fault at page 0. Best regards Alexei

2 1

Problems compiling Fiasco
by Prasad 24 Aug '02

24 Aug '02

hi, i am new to fiasco. When trying to compile it using the sources from the CVS i am getting a lot of errors. I know that the type of errors are required for any guidance, but would like to know some details about the preferred compiler, OS etc: This would prove very helpful to me. Thanking you all for any help, Prasad. -- Failure is not an option

2 1

Usermode Fiasco, X.2 spec
by Andreas Rottmann 23 Aug '02

23 Aug '02

Hi! <disclaimer>Yes, I know I might be annoing</disclaimer> August has come, and I once again ask for the status of the Fiasco usermode port, as I am eager to try it. Furthermore, I'd like to know if there is/will be any effort to implement the X.2 (upcoming version 4) L4 API building on the Fiasco codebase (that would be quite interesting, since the HURD L4 port will use the X.2/4 API). Regards, Andy -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rottmann(a)gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62

2 3

Hello, world!
by Nick Name 04 Jul '02

04 Jul '02

Hi all, just wanted to introduce myself: I am an italian computer science student, and a newcomer in the µkernels stuff ... so I am trying fiasco (by now, still trying to understand bochs, to be able to test it). One of my wish is to experiment with functional programming (with Haskell) and µkernels to see if a standalone system could be mainly functional. But... here comes my first wish: User-mode-fiasco ! Is it already useable? thanks, Vincenzo

1 0

user-level port
by Andreas Rottmann 27 Jun '02

27 Jun '02

Hi! I hope this is the right place to ask. (If not, please point me there ;-)) I have read on the Fiasco homepage that Fiasco is beeing/was ported to run as a user-level process under Unix. What is the state of this project? And what is the mentioned CVS branch? However, I am interested in this. A nice way to go would be to port Fiasco to a386 (http://a386.nocrew.org/), IMO. I don't know if I can be of any help, since I haven't (yet) done much kernel-level hacking... Regards, Andy -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rottmann(a)gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62

3 5

(no subject)
by Luís Alberto Lucas 14 Jun '02

14 Jun '02

Hello folks, First of all I'd like to thank you for such a development environment: linux over L4. After some time reading the faq and the mail list I could make it work. But now some questions: 1) Is X Window System still not running under l4linux ? I got: sys_iopl() called (8 times) "XF86_SVGA" (22.00) raised page fault (error =04) at 000000004 (vm_area can't grow down). 2) I'd like to run "kernel debugger" after l4linux boots (just for fun). Kernel debugger manual says that I could by pressing ESC but when I try, my system halts. 3) It seems that command "halt" doesn't work. It goes till "unmounting local file systems" and stops. "CTRL ALT DEL" still works. Thanks in advance. Luís Alberto Lucas lalucas(a)cefetpr.br

2 1

RE: L4 SCSI driver
by Volkmar Uhlig 11 Jun '02

11 Jun '02

> >>>>> On Mon, 10 Jun 2002 12:59:16 +0200, Uwe Dannowski > <Uwe.Dannowski(a)ira.uka.de> said: > UD> dmiller wrote: > >> does any version of L4 have an adaptec SCSI driver? > > UD> No version of L4 has any device drivers (except for maybe > an interrupt > UD> controller driver). > > This answer could be from a mathematician. 100% correct and 100% > useless. > > I guess Don's question could be rephrased as "has an adaptec SCSI > driver been ported to run on any version of L4". At UNSW we had a SCSI > driver running on L4/MIPS, what's the status of that? Btw, you should not forget that we also have a quite rich set of drivers running within a POSIX emulation layer -- L4Linux. Also 100% correct and I'm definitely no mathematician ;) - Volkmar

1 0

L4 SCSI driver
by dmiller 10 Jun '02

10 Jun '02

dear l4-hackers does any version of L4 have an adaptec SCSI driver? we are trying to add an adaptec 2940UW SCSI driver to the Sombrero Single Address Space OS I have taught L4 as the topic of my OS internals course (using the L4 version available from UNSW) - but can't find such a driver in that source thanks for any info you have on this don miller -- Donald S. Miller Associate Professor Computer Science and Engineering Department Arizona State University Tempe, AZ 85287-5406 email: donald.miller(a)asu.edu http://www.eas.asu.edu/~sasos phone: (480)-965-5935 Fax: 480/965-2751

3 2

DE use
by luke.hart＠sysmedia.com 02 May '02

02 May '02

All, The latest version of L4 (from CVS) and probably earlier ones, check for the debug extensions. Does it actually use them? I ask this since Bochs, does not set the DE bit in the CPUID or support these extensions. I have done a search for usage of DRx (where x is 0-7) in the source, but couldn't find any references. Is it safe to just remove the check for DE? Thanks for any info., Luke

3 2

RE: DE use
by Volkmar Uhlig 01 May '02

01 May '02

What kernel? Hazelnut or FIASCO? > -----Original Message----- > From: luke.hart(a)sysmedia.com [mailto:luke.hart@sysmedia.com] > Sent: Wednesday, May 01, 2002 1:42 AM > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: DE use > > > All, > > The latest version of L4 (from CVS) and probably earlier > ones, check for the > debug extensions. Does it actually use them? I ask this since > Bochs, does > not set the DE bit in the CPUID or support these extensions. > > I have done a search for usage of DRx (where x is 0-7) in the > source, but > couldn't find any references. Is it safe to just remove the > check for DE?

2 1

L4 SCSI driver
by dmiller 19 Apr '02

19 Apr '02

Gernot a quick question does any version of L4 have an adaptec SCSI driver? we are trying to add an adaptec 2940UW SCSI driver to Sombrero thanks for any info you have on this don -- Donald S. Miller Associate Professor Computer Science and Engineering Department Arizona State University Tempe, AZ 85287-5406 email: donald.miller(a)asu.edu http://www.eas.asu.edu/~sasos phone: (480)-965-5935 Fax: 480/965-2751 --

1 0

L4 for asm-free OS'es?
by William A. Gatliff 09 Apr '02

09 Apr '02

Guys: I'm an L4 newbie. I've booted it on my PC, I've read a lot of the online docs, and I've looked at some of the code. But I've been doing embedded systems for more than ten years now, so I know a thing or two about computers and operating systems. I'm interested in using L4 as a foundation for a new, yet-to-be-written Linux replacement intended primarily for use in embedded systems. My main motivations are for an OS that is portable, is understandable, has low interrupt latency, and has a small memory footprint. I'm thinking along the same lines as L4-Linux, but my OS would probably be written in C++ and make more use of L4 servers for hardware i/o. Here are my questions: One of the L4 manuals I've read says that when an OS running under L4 starts, it should take all free memory from sigma0 and then manage the pages itself. To me, this means that the OS has to know how to interact with the host CPU's MMU hardware, which is obviously hardware-dependent and therefore undesirable in a portable OS. It also appears to be redundant--- sigma0 already knows how to work the MMU. Performance issues aside, would letting sigma0 do page mapping and unmapping eliminate the need for an OS running under it to know how the MMU interface works, and thereby make the OS a little more portable? Is this a reasonable approach? What is the likelihood that an L4-based OS would need no assembly language at all, other than the syscall interface? I'm thinking along the lines of "to port this OS to your CPU, just port L4 and then recompile the OS sources." I'm eyeing ARM, MIPS, SH and x86 targets--- all of which I work with every day. I have single-board computers representing all four architectures in my lab here right now, and I'm doing something with all of them almost all the time. That's why portability is important to me. My customers think Linux is great because it's more portable than the alternatives, but I think it isn't nearly portable enough. And it scores low marks for understandability, interrupt latency and footprint. Oh, and debuggability---I love your "KD:" prompt! :^) Thanks! b.g. -- Bill Gatliff bgat(a)billgatliff.com

5 6

RE: L4 for asm-free OS'es?
by Josh English 09 Apr '02

09 Apr '02

I was told that BeOS used a similar C++ structure. Though I have no idea how it was really implemented. - Josh -----Original Message----- From: Patrick Strasser [mailto:past@sbox.tugraz.at] Sent: Monday, April 08, 2002 5:29 PM To: bgat(a)billgatliff.com Cc: l4ka(a)ira.uka.de; l4-hackers(a)os.inf.tu-dresden.de Subject: Re: L4 for asm-free OS'es? William A. Gatliff wrote: > A lot of what I see happening in the C parts of Linux could be done > *so* much better with C++. I'm thinking of an OO-oriented driver > model as an example, rather than just a soup of C functions that you > have to invoke in the proper order for things to work right. "Want to > right a USB driver? Well then just inherit from USBDriver and fill in > these functions for the bulk transfers." You know, like that. :^) You probaly want to have a look at MacOS X / Darwin and its IOKit. Thats exactly what they do. Patrick _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

1 0

IDL4 0.8.1 released
by Andreas Haeberlen 06 Apr '02

06 Apr '02

Hello L4 hackers, IDL4 is now available for download from the L4Ka home page. IDL4 is a stub-code generator for the L4 platform. It generates communication stubs from interface definitions written in a specification language such as CORBA IDL or DCE IDL. It also uses knowledge about the hardware platform and the microkernel to optimize the performance of the generated code. Some features: o Supports CORBA IDL (recommended) and DCE IDL o Backends available for Hazelnut and Pistachio o Client stubs use CORBA C language mapping o Type import from C/C++ code o Modular design; easily extensible For more information please visit http://l4ka.org/projects/idl4/ - Andreas --- Andreas Haeberlen System Architecture Group, University of Karlsruhe, Germany haeberlen(a)ira.uka.de, phone: +49 (721) 608-4055

1 0

Fiasco and linux22 -- RMGR: overlapping modules problem
by Ian Duggan 23 Mar '02

23 Mar '02

I'm trying to get linux22 working on the recent CVS version of fiasco. I've run into an obstacle that hopefully someone here can assist with. When my machine is booting up, I get an "overlapping modules" error that looks like this: ------------------------------------------------------- RMGR: loading /sigma0 RMGR: loading kernel /main RMGR: overlaps: 00300000-00301c78 : /main RMGR: 00100000-0015fc69 module 02: 001e6000-00345be4 : /glinux root=/dev/hdb1 init=/bin/sh overlaps, 1, mem_high = 0x09f9fc00 RMGR: overlapping modules ------------------------------------------------------- 00300000 is the starting link address of /main 00100000 is the starting link address of /rmgr I thought that maybe I needed to move the starting link address of /glinux, so I adjusted the corresponding vmlinux.lds file used for linking linux22, but there is no change in the result. I verified all code start/end addresses using objdump -d. Just now I noticed that 001e5000 is where GRUB is loading the /glinux image to. Grub shows: [Multiboot-modules @ 0x1e6000 ... when it is starting up. The problem seems to be that rmgr is calling check_inside_myself and croaking when it sees that the /glinux module overlaps it. I don't understand why the /main and /rmgr images are being loaded to their correct link locations, but /glinux is not. Is grub supposed to load things directly to the correct location, or are the modules supposed to be relocated at some point in the boot process. Any suggestions on what to look at? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

4 6

Re: L4Env
by Ian Duggan 11 Mar '02

11 Mar '02

What is the latest status on the L4ENV stuff? --Ian > > Ian Duggan <ian(a)ianduggan.net> writes: > > > Where can I find out more information about the L4Env project? I'm > [...] > > presentation can be foud at > > http://os.inf.tu-dresden.de/~reuther/helmuth.pdf > > http://os.inf.tu-dresden.de/~reuther/helmuth_slides.pdf > > There is also a small webpage at > http://wwwos.inf.tu-dresden.de/~ch12/diplom/diplom.xml > > I will put more up-to-date documentation (doxygen) about my implementation on > it as far as I cleaned up the sources. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

2 1

(no subject)
by tinker1 french 12 Feb '02

12 Feb '02

still looking for way to find pharmacys directory for overseas. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

1 0

L4 Version X.2 announcement
by Uwe Dannowski 28 Jan '02

28 Jan '02

The L4Ka Team is happy to announce the availability of the L4 microkernel API specification, Version X.2. The specification can be downloaded in PDF format from the L4Ka web-site (http://l4ka.org/). It should be noted that the Version X.2 specification is experimental. Future revisions may contain modifications and introduce incompatibilities with the current revision. It is nevertheless our intention that the amount of changes to the specification should be small, and that the X.2 specification should deviate as little as possible from the forthcoming Version 4 specification. The L4Ka Team is currently working on providing a reference implementation for the specification. No release date has been chosen. - The L4Ka Team

1 0

L4/Alpha palcodes
by Goswin Brederlow 25 Jan '02

25 Jan '02

Hi, I hope this is the right place, havent read anything here for ages. I was wondering whether the palcodes used by L4 on Alpha are disjunct to the ones used by OSF / BSD / Linux. If not could they be made disjunct? The idea I have in mind is to make a module for linux that catches the L4 syscalls and throws them back into user-space. That way a L4 environment could be setup within linux. It would be much like user-space-linux and would save a lot of reboots just to test out a few bytes of code. On the other hand, inside L4 you could do the same with OSF / BSD / Linux syscalls and thus run their binaries under L4. (You want to run Netscape under L4? Or Mathematica? Or something as simple as xemacs and gcc?) A l4-linux for alpha would also need those changes (if any) I believe. MfG Goswin

4 5

RE: L4/Alpha palcodes
by Sebastian Schoenberg 22 Jan '02

22 Jan '02

Yes, they were set to numbers which do not conflict with OSF/Linux/WinNT. A PALcall instuction is coded as cmd (6 bits) = 0, number (26 bits). There are two ways of calling PALcode: A direct way, where a certain address is called, or an indirect way, which must examine the calling instruction to jump to the right place. All L4Alpha PALcalls are located at the end of direct-callable PALcalls, hence they are fast and do not conflict with any other system Seb > -----Original Message----- > From: Daniel Potts [mailto:danielp@cse.unsw.edu.au] > Sent: Dienstag, 22. Januar 2002 09:50 > To: Goswin Brederlow > Cc: l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: L4/Alpha palcodes > > > On 22 Jan 2002, Goswin Brederlow wrote: > > > Hi, > > > > I hope this is the right place, havent read anything here for ages. > > > > > > I was wondering whether the palcodes used by L4 on Alpha > are disjunct > > to the ones used by OSF / BSD / Linux. > > yes they are. An exception is l4_whoami which is an > experimental syscall anyway. I think it maps directly to the > OSF whoami call. > > > > > If not could they be made disjunct? > > > > > > The idea I have in mind is to make a module for linux that > catches the > > L4 syscalls and throws them back into user-space. That way a L4 > > environment could be setup within linux. It would be much like > > user-space-linux and would save a lot of reboots just to test out a > > few bytes of code. > > heh :) That would be an interesting project. I'd be > interested to know how (if) you will deal with device > drivers, memory etc. > > > On the other hand, inside L4 you could do the same with OSF / BSD / > > Linux syscalls and thus run their binaries under L4. (You > want to run > > Netscape under L4? Or Mathematica? Or something as simple as xemacs > > and gcc?) > > > > > > A l4-linux for alpha would also need those changes (if any) > I believe. > > Yes that is how we would run unmodified Linux/Alpha binaries on L4.. > > Cheers, > Daniel > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-> dresden.de/mailman/listinfo/l4-hackers >

1 0

L4\UltraSPARCIIi?
by Crusher 20 Jan '02

20 Jan '02

I'm a graduate student at CSUS (California State University Sacramento). I was looking around the Internet for a Master's Project. I decided that since no one has ported L4 to the UltraSPARCIIi I would attempt it (as this is my first kernel, I'm not expecting too much), especially since the school has plenty of Sun machines around. I do already have a Sun Ultra 5 workstation and the development environment just about setup. Before I really started in on my project, I just wanted to make sure that a L4 port to the UltraSPARC isn't in the works or has been completed. Otherwise, I was hoping someone has done system work with the UltraSPARC and would be willing answer some of my UltraSPARC specific technical questions that I know will come up. Scott Tanaka

1 0

OSKit-Problems with newer glibc
by imi＠inf.tu-dresden.de 17 Jan '02

17 Jan '02

Hi Are there any reported solutions for compiling the oskit1.0 that comes with l4 with installed glibc 2.2.4 or newer? On my machine (Debian "sid", gcc 2.95.4) it throw a linker error while linking unix/linux/sbrk-hack.o together with libc.a because duplicate symbol __libc_multiple_libcs. The sbrk-hack's only purpose seems to be defining these global variable (as an int). Maybe this was an error in libc and got fixed in 2.2.4? However when I compiled under glibc 2.1.3-10 (and gcc 2.95.2) it works... -- Immanuel Scholz, PGP: (Work 0x9216F1E7, Home 0x3B5DC02D)

3 3

OSKit-Problems with newer glibc
by imi＠wh9.tu-dresden.de 16 Jan '02

16 Jan '02

Hi Are there any reported solutions for compiling the oskit1.0 that comes with l4 with installed glibc 2.2.4 or newer? On my machine (Debian "sid", gcc 2.95.4) it throw a linker error while linking unix/linux/sbrk-hack.o together with libc.a because duplicate symbol __libc_multiple_libcs. The sbrk-hack's only purpose seems to be defining these global variable (as an int). Maybe this was an error in libc and got fixed in 2.2.4? However when I compiled under glibc 2.1.3-10 (and gcc 2.95.2) it works... -- Immanuel Scholz, PGP: (Work 0x9216F1E7, Home 0x3B5DC02D)

1 0

2nd release of L4Ka/Hazelnut
by Uwe Dannowski 14 Dec '01

14 Dec '01

Hi L4 hackers and users, after a long wait it's again time to announce a new release of L4Ka/Hazelnut. L4Ka/Hazelnut still implements the L4 Version X.0 API on x86 and ARM processors. This time around, however, it outperforms Jochen's x86 assembly kernel. Parts of the kernel have also been redesigned for better portability. Among the goodies added since the last release are: o Small Address Spaces o IPC FastPath(tm) o FPU virtualization o Enhanced kernel debugger (e.g., embedded disassembler and profiling support) o Pentium4 support o One year's worth of bugfixes For more information please visit http://l4ka.org/.

1 0

RE: l4 for 386
by Sebastian Schoenberg 08 Nov '01

08 Nov '01

Well, sort of or not. You have a mirrored region for kernel- accessed read-only memory regions where the kernel potentially might write to. You don't need a mirrored region for all writable pages. Seb > -----Original Message----- > From: Espen Skoglund [mailto:esk@ira.uka.de] > Sent: Mittwoch, 7. November 2001 13:31 > To: Sebastian Schoenberg > Cc: jhuntnz(a)users.sourceforge.net; l4-hackers(a)os.inf.tu-dresden.de > Subject: RE: l4 for 386 > > > [Sebastian Schoenberg] > > This can be done by using different regions for read and write > > access. For tasks where the write-protection is neccesary, a page > > is mapped only to the writeable area if the page is writable in the > > page-table. > > I'm not sure I know what you mean here. Are you suggesting that we > divide the user-accessible virtual memory into two equally sized > mirrored regions; one for read-only and one for read-write? > > eSk >

1 0

RE: l4 for 386
by Sebastian Schoenberg 07 Nov '01

07 Nov '01

This can be done by using different regions for read and write access. For tasks where the write-protection is neccesary, a page is mapped only to the writeable area if the page is writable in the page-table. The task is to find all relevant writes in the current version. Seb > -----Original Message----- > From: Michael Hohmuth [mailto:hohmuth@innocent.com] > Sent: Mittwoch, 7. November 2001 12:35 > To: jhuntnz(a)users.sourceforge.net > Cc: l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: l4 for 386 > > > Jonathan Hunt <jhuntnz(a)users.sourceforge.net> writes: > > > Yes I would but interested in porting this to a 386. Could anyone > > give me some more information on what would be required to > > change. (The FAQ is rather brief). I understand the the CR0::WP bit > > enables an exception when a fully privileged task (such as the > > kernel task) writes to a read-only page but when does this happen > > that I can check explicitly for it? > > Offhand I can think of two places that rely on page faults when > writing to write-protected pages: > > - When reading from a nonexisting thread's thread-control block (TCB), > the TCB's virtual-memory region is backed by a read-only zero-filled > page. This page gets replaced with a newly-allocated page only when > a write access occurs. This mechanism is intended to prevent > malicious threads from causing the kernel to allocate hundreds of > pages by attempting to send IPC to (or otherwise modify) nonexisting > threads. > > In a first 386 version, this protection mechanism can just > be disabled. > > - In memory-copying IPC operations (and some other operations that > write to the user address space, like exception delivery), > the kernel > relies on page faults when accessing write-protected user pages. > > This could be approximated by checking for write permission in the > copy operation, like Linux does. > > Michael > -- > hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de > http://home.pages.de/~hohmuth/ > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >

3 2

Re: l4 for 386
by Michael Hohmuth 07 Nov '01

07 Nov '01

Jonathan Hunt <jhuntnz(a)users.sourceforge.net> writes: > Yes I would but interested in porting this to a 386. Could anyone > give me some more information on what would be required to > change. (The FAQ is rather brief). I understand the the CR0::WP bit > enables an exception when a fully privileged task (such as the > kernel task) writes to a read-only page but when does this happen > that I can check explicitly for it? Offhand I can think of two places that rely on page faults when writing to write-protected pages: - When reading from a nonexisting thread's thread-control block (TCB), the TCB's virtual-memory region is backed by a read-only zero-filled page. This page gets replaced with a newly-allocated page only when a write access occurs. This mechanism is intended to prevent malicious threads from causing the kernel to allocate hundreds of pages by attempting to send IPC to (or otherwise modify) nonexisting threads. In a first 386 version, this protection mechanism can just be disabled. - In memory-copying IPC operations (and some other operations that write to the user address space, like exception delivery), the kernel relies on page faults when accessing write-protected user pages. This could be approximated by checking for write permission in the copy operation, like Linux does. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

l4 for 386
by Jonathan Hunt 07 Nov '01

07 Nov '01

Hi, Is there a version of l4 for a Intel 386. I am wanting to experiment with l4 and have a spare i386 to play with but nothing else. None of the "virtual machine" solutions look very nice. If not is anybody working on a version? Any plans? Thanks, Jonny -- Jonathan Hunt (The Real Jonathan Hunt) <jhuntnz(a)users.sf.net> Jabber at jhuntnz(a)jabber.com "He is no fool who gives what he cannot keep to gain what he cannot lose." Jim Elliot

3 3

How to unsubscribe
by Li Bing 05 Nov '01

05 Nov '01

Dear all, Please tell me how to unsubscribe the list. I am very appreciated for your help! LB _.--"""--._ .' '-. `. __/__ (-. `\ \ /o `o \ \ \ \ _\__.__/ )) | | ; .--;" | | \ ( `) | | \ _|`---' .' _, _| | `\ '`_\ \ '_,.-';_.-`\| \ \_ .' '--'---;` / / |\ |_..--' \ \'-'.' .--'.__/ __.-; `"` (___...---''` \ _/_ \ /ASU\ libing(a)asu.edu \___/ 480-965-9038(L), 480-829-8492(H) http://www.public.asu.edu/~libing

2 1

Why distinction between task and thread ?
by Robert Kaiser 05 Nov '01

05 Nov '01

Hello all, this may be a stupid question, but... It seems to me that address spaces and activities (to avoid the words "task" and "thread") are othogal concepts. What is the reason for L4 to not keep them seperate in it's API ? (i.e. there is task_new to create an activity _and_ an address space and there is lthread_ex_regs to create an activity in an already existing address space). It would seem a lot "cleaner" to me if there was one system call to create an address space (without any activity in it) and another one to create an activity, specifying as a parameter the address space in which it will execute. Is there a reason (perhaps security ?) why it wasn't done like that in L4 ? Thanks for any insights. Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

2 1

tftp problems
by Ian Duggan 05 Nov '01

05 Nov '01

I'm having problems getting L4 to boot using grub and tftp. My grub config looks like this: title = ChacmOS on Sopwith kernel = (nd)/tftpboot/chacmos/rmgr -sigma0 -roottask module = (nd)/tftpboot/chacmos/x86-kernel module = (nd)/tftpboot/chacmos/sigma0 module = (nd)/tftpboot/chacmos/booter module = (nd)/tftpboot/chacmos/memsvr module = (nd)/tftpboot/chacmos/namesvr module = (nd)/tftpboot/chacmos/ext2fs module = (nd)/tftpboot/chacmos/ramdisk module = (nd)/tftpboot/chacmos/shell It gets as far as retrieving rmgr via tftp (I see it get requested in the logs), but the machine reboots itself as it is loading the rmgr image. It prints out the "[Multiboot-elf blah blah" stuff and does a reboot before anything related to x86-kernel is printed to the screen. This happens very quickly. If I move the first two files to the boot floppy I am using, things boot fine. This config works: title = ChacmOS on Sopwith (Floppy) kernel = (fd0)/rmgr -sigma0 -roottask module = (fd0)/x86-kernel module = (nd)/tftpboot/chacmos/sigma0 module = (nd)/tftpboot/chacmos/booter module = (nd)/tftpboot/chacmos/memsvr module = (nd)/tftpboot/chacmos/namesvr module = (nd)/tftpboot/chacmos/ext2fs module = (nd)/tftpboot/chacmos/ramdisk module = (nd)/tftpboot/chacmos/shell There is something in the grub/tftp boot process that differs from what it does when loading the files from floppy that causes problems. It seems that maybe it is starting to execute stuff before it has everything in place? I am using grub 0.90 from the Debian source. Any ideas? What else can I do to try to track down the problem? --Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

2 1

Re: vk_l4 -- CVS Setup
by Lars Reuther 30 Oct '01

30 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > BTW, is anyone in the L4 community currently implementing a pager task > that would resemble Mach-VM or, even better, UVM? This is of general > interest to all developers of L4-based OS-personalities, not just > l4-hurd. Getting all the memory from sigma0 upon startup is not very sexy ;-). The current VM management model of L4Env is roughly based on the ideas described in <ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Aron_PJLED_01.ps.gz>. See also the documentations for the L4 Region Mapper and Dataspace Manager at the L4 Developer's Bibliography mentioned by Michael. Lars -- Dipl.-Inf. Lars Reuther Dresden University of Technology Department of Computer Science Operating Systems Research Group Phone: +49 (351) 463-38401 Fax: +49 (351) 463-38284 reuther(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/~reuther/

1 0

Old and new L4 APIs (was Re: L4Hurd at Sourceforge)
by Michael Hohmuth 30 Oct '01

30 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > If the L4 people could provide us with a coherent view of the current > (and upcoming) APIs and C-Bindings, that would be _great_! (hint, hint!) The most coherent view on current APIs is available at <URL:http://os.inf.tu-dresden.de/L4/bib.html>. The L4 people in charge of the new L4 API (the Karlsruhe guys) have decided to circulate the upcoming specification in a limited way first to keep discussion short and efficient. They deemed this necessary because they felt that the current draft is not self-explanatory enough to be consumed by larger audiences without overloading its developers with questions. Let's respect them regarding their decision. In the meantime (and in general), I suggest using library APIs that will remain unmodified regardless of kernel version. Please have a look at the upcoming L4 environment, which exists now and is relatively well documented <URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env>. A release is forthcoming as soon as the L4Env developers feel that their users understand and are comfortable with their libraries. Try giving them this impression! Or even better: Help them by writing a user's guide for L4Env! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: vk_l4 -- CVS Setup
by Farid Hajji 30 Oct '01

30 Oct '01

> At Thu, 25 Oct 2001 12:01:56 +0200, > Christian Ceelen wrote: > > Where could I find these research papers? > > http://www.netbsd.org/Documentation/kernel/uvm.html > http://www.usenix.org/events/usenix99/full_papers/cranor/cranor_html/ > http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz > http://www.ccrc.wustl.edu/pub/chuck/psgz/osdi99.ps.gz > http://www.ccrc.wustl.edu/pub/chuck/psgz/disstalk.ps.gz > > Okuji BTW, is anyone in the L4 community currently implementing a pager task that would resemble Mach-VM or, even better, UVM? This is of general interest to all developers of L4-based OS-personalities, not just l4-hurd. Getting all the memory from sigma0 upon startup is not very sexy ;-). -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.

1 0

L4 device-driver framework (was Re: vk_l4 -- CVS Setup)
by Michael Hohmuth 29 Oct '01

29 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes in l4-hurd: > [...] We'll probably also need glue code from OSKit to drop in the > driver framework from Michael. To clarify: There are two L4 device-driver frameworks that are currently in use, neither of which is ``Michael's framework.'' - One is a port of the OSKit to L4. It allows running OSKit applications on top of L4 in user mode, including applications that use OSKit's device drivers (which are mostly inherited from FreeBSD and Linux). It can be used to get applications up and running in short time on x86 machines, but it is somewhat slow, produces huge binaries (most of the time, the OSKit startup code links in *all* device drivers of a class) and is not portable (the OSKit really only runs on x86). Our distribution (available as part of our "l4" CVS module) includes a number of example programs lifted straight from the set of examples that came with the OSKit, including a "finger" client and a filesystem example. Here is the technical report I wrote on it: <URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz> - The other framework is a new development that is intended to fix the OSKit problems I mentioned, developed mainly by Christian Helmuth and Lars Reuther. This framework is intended to allow dropping the source code of one Linux driver inside it, recompiling, and ending up with a working L4 device driver. This framework does not use the OSKit (AFAIK), but is based on our new L4 environment, ``L4Env''. A prototype for character-device drivers exists, but hasn't been released yet. Preliminary L4Env docs: <URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env> A description of the device-driver framework (Christian's diploma thesis, in German only): <URL:http://os.inf.tu-dresden.de/~ch12/sub/diplom.ps> Please bug the DROPS developers concerning releasing this stuff. :-) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Is this list active?
by Ian Duggan 23 Oct '01

23 Oct '01

Is this list still active? Are there other L4 lists that I should be on as well? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

2 1

Re: Writing device drivers for L4 (was Re: Hurd/Mach on L4)
by Michael Hohmuth 14 Oct '01

14 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > > Currently, some of my colleagues are working on a framework that > > allows you to (more or less) drop a Linux driver in a preconfigured > > source tree and get a working driver that runs on the x86 L4 kernels > > (L4/x86, Fiasco, L4KA). This framework, which will work with the > > L4Env environment we're developing, is not quite ready yet, but it > > might be worth the wait. > > Will the drivers run in userland on top of a vanilla L4 kernel? Yes, they will. > I'm wondering wether it would be possible to use (RPC?) the driver > tasks directly from OS personalities like L4Linux, (L4BSD if someone > wants to repeat the Lites experience on L4 ;-)) or the Hurd, possibly > even simultaneously? Yes. We have been working on stub drivers for L4Linux that use external user-level drivers concurrently with (non-Linux) tasks. I'm not sure right now which stub drivers we currently provide, but I believe we already support console drivers and block-device drivers. > > As an alternative, consider using the OSKit. We have developed a > > compatibility library that allows you to run applications using the > > OSKit (including the OSKit's device drivers) on top of L4. This work > > is a bit unpolished and the drivers are slow, but it's quite easy to > > Good point. However, wouldn't it be necessary to link the driver > libs to the Kernel? This is exactly what we want to avoid in the > OSKit-Mach case sometime in the future (*Sigh*). No, the drivers run completely on user level. The OSKit has well-defined interfaces for low-level OS services such as IRQ allocation and delivery. Reimplementing these interfaces for a target system such as L4 (in particular parts of liboskit_dev and liboskit_kern) makes it possible to port OSKit drivers to the target system. OSKit drivers do not care whether they run on user level or in kernel mode if all services they expect from liboskit_dev and liboskit_kern are available. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Writing device drivers for L4 (was Re: Hurd/Mach on L4)
by Michael Hohmuth 12 Oct '01

12 Oct '01

Farid Hajji <farid.hajji(a)ob.kamp.net> writes in l4-hurd: [...] > The second pressing point is to write/port a very small subset of device > drivers to L4. We need a native L4 driver for ATAPI (or SCSI?) disks, > so that the pager can use a real disk as backing store, and so that > we can port a filesystem as well ;). Here too, no-one volunteered yet. We in Dresden have extensive experience in porting Linux device drivers to run directly on top of L4, so if you guys have questions, don't hesitate to ask on the L4-hackers mailing list <l4-hackers(a)os.inf.tu-dresden.de>. Currently, some of my colleagues are working on a framework that allows you to (more or less) drop a Linux driver in a preconfigured source tree and get a working driver that runs on the x86 L4 kernels (L4/x86, Fiasco, L4KA). This framework, which will work with the L4Env environment we're developing, is not quite ready yet, but it might be worth the wait. As an alternative, consider using the OSKit. We have developed a compatibility library that allows you to run applications using the OSKit (including the OSKit's device drivers) on top of L4. This work is a bit unpolished and the drivers are slow, but it's quite easy to use. I even wrote a technical report on it: <URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz>. (You can find this and other reports in the L4 Developer's bibliography at <URL:http://os.inf.tu-dresden.de/L4/bib.html>.) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Re: Cross Compile Needed?
by Michael Hohmuth 11 Oct '01

11 Oct '01

Ian Duggan <ian(a)ianduggan.net> writes: > I'm working to try to build the fiasco kernel for a pentium machine that > I have. I'm working from a Debian PIII. Will I need to build a > cross-compiler to produce code for the pentium machine? No, you can use your Linux installation's native compiler. > Working from the fiasco CVS, I can see how to invoke the --host options > for "configure" of oskit and oskit10. Is there anything similar for > doing this with the L4 module? No, the compiler L4 uses is configured in l4/Makeconf. On Linux/x86 systems, it's just `gcc', on other systems its usually `i386-linux-gcc'. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Code Repository
by Michael Hohmuth 11 Oct '01

11 Oct '01

Ian Duggan <ian(a)ianduggan.net> writes: > Who is the maintainer for the current L4/Fiasco CVS? If I have patches > to add to L4/Fiasco, to whom do I send them? The best place to send them to is the Dresden's bug-tracking system at <fiasco-bugs(a)os.inf.tu-dresden.de> (don't be fooled by the name -- use this address for L4- and Fiasco-specific changes alike). If your patches are Fiasco-specific, you can also send them for review directly to <fiasco-core(a)os.inf.tu-dresden.de>. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Code Repository
by Ian Duggan 11 Oct '01

11 Oct '01

Who is the maintainer for the current L4/Fiasco CVS? If I have patches to add to L4/Fiasco, to whom do I send them? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

1 0

Cross Compile Needed?
by Ian Duggan 09 Oct '01

09 Oct '01

Hi, I'm working to try to build the fiasco kernel for a pentium machine that I have. I'm working from a Debian PIII. Will I need to build a cross-compiler to produce code for the pentium machine? Working from the fiasco CVS, I can see how to invoke the --host options for "configure" of oskit and oskit10. Is there anything similar for doing this with the L4 module? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian(a)ianduggan.net http://www.ianduggan.net

1 0

GNULLI
by Frédéric BOYER 27 Sep '01

27 Sep '01

Hello, I think that the best way to "port" GNAT on top of L4 is to port GNARL and rewrite GNULL lib. GNAT is the run time library but is almost portable. Modification in this package will be minor (Exception, interuption, etc). GNULL (Low Level lib) have to be rewritten entierly. Actually GNULL is port on Pthead lib & win thread. There are minor port to jtk (an other implementation of thread on linux computer .. it's a native one) or FSU. There are also port on micro kernel as Ravenskar or Mach (See MarteOS project). Maybe it could be cool to implements the GNULLI on top of L4, by define an interface beetween L4 & GNULLI to make it portable beetween implementation. After we could write some servers to implements the entire GNAT lib and Posix 1003.5 binding. But it's another story. Some specialized annexes could be implemented too (Real time, Distributed sys, etc.) best regards .. Frederic. ___________________________________________________________ Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr ! Yahoo! Courrier : http://fr.mail.yahoo.com

1 0

gnarl on top of L4
by Frédéric BOYER 27 Sep '01

27 Sep '01

Hello, Just a little word about GNAT library design. GNAT lib is design over 3 layers. 1/ Applications 2/ The second layer (GNARL) is a threads independant manipulation lib. This lib is needed by the compiler and is the Run Time Lib of GNAT. 3/ the GNULL (Low level) is the OS/Hardware dépendant lib to implements Thread system. The lib is often build on Posix Thread. On W2000, this lib is implemented on top of win32 lib. Interface beetween Application & GNARL is called GNARLI, interface beetween GNARL & GNULL is called GNULLI. If you want to write servers in Ada with GNAT on top of L4, you can do it in several ways : 1/ Use pragma No_Run_Time. In this case, GNAT never use is lib. You can no more use task, hight level array fonctionnalities, .. see GNORT (no_run_time) documentation on adacore web site 2/ Implement the GNULLI interface. Ravenskar ORK use this way to port GNAT on their micro kernel. 3/ Implement the GNARL .. I gonna to choose the second way. Maybe we could defined a interface beetween GNULL & L4 to be hardware/kernel independ, to make our version of GNULL portable beetween L4 implementation. best regards .. Frederic. ___________________________________________________________ Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr ! Yahoo! Courrier : http://fr.mail.yahoo.com

1 0

L4 & Ada
by Frédéric BOYER 26 Sep '01

26 Sep '01

Hello, My project is not a real project in sens that it's only for fun. My main goal is to provide a little (R.T. if possible) Unix like O.S. as QNX or Plan9 on top of L4. I start on top of a micro kernel write in C, but if an Ada implementation exists (and works ;)), I will choose it will be choosen in priority. For now a study design concept of the O.S. By now, I follow exactly the User Guide Manual, with the typical OS example. I've created a sourceforge site & M.Ls. (search ADX). There is no traffic actually. Best regards .. Frédéric. ___________________________________________________________ Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr ! Yahoo! Courrier : http://fr.mail.yahoo.com

2 3

GNURL on top of L4
by Frédéric BOYER 25 Sep '01

25 Sep '01

Hello .. I'd like to find people here who can help me to build GNURL on top of L4 (GNAT Run time lib). I'd like to use L4 to develop an RT unix like O.S., but I'd like to implement it in Ada. Any people interested ? Is there people who know Ada here ? bye bye Frederic BOYER. ___________________________________________________________ Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr ! Yahoo! Courrier : http://fr.mail.yahoo.com

2 1

Re: GNURL on top of L4
by Michael Hohmuth 25 Sep '01

25 Sep '01

Frédéric BOYER <askliepios(a)yahoo.com> writes: > I'd like to find people here who can help me to build > GNURL on top of L4 (GNAT Run time lib). I'd like to > use L4 to develop an RT unix like O.S., but I'd like > to implement it in Ada. > > Any people interested ? Is there people who know Ada > here ? This sounds like a cool project. Do you envision a particular application, or are you interested in it just for hack value? Our group in Dresden currently has no ADA expertise or experience. However, depending on your project's focus, we might be willing to help out by directing students to your project and allowing them to earn credits this way. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Recursive mapping trees?
by Jean Wolter 10 Sep '01

10 Sep '01

Martin Young <my(a)siroyan.com> writes: > Thinking it through however it's obvious that a task A can map a page P > to task B which can then map it back to task A at a different virtual > address. Is this allowed in L4? (I assume it is) Is it useful? Could > I get away with not allowing it? I ask because my initial > implementation includes a quick index from a taskid to a node in the > mapping tree (to avoid recursion rather than for speed) but this > requires that each task has only a single entry. L4Linux would not work on your L4 implementation, since we need more then one mapping for a page in the same address space to be able to implement vmalloc() and friends. To do this we currently map one page to a special helper task which immidiatly grants it back those creating a new mapping for the same page in the address space of L4Linux (we do this since for some reasons Jochen's L4 version didn't support intra task mappings, but I forgot the reasoning behind this design decision). Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

2 1

Recursive mapping trees?
by Martin Young 07 Sep '01

07 Sep '01

Hi, I've been adding mapping trees to my implementation of L4 and I have a question... The L4 reference manual states that address spaces are constructed recursively. Up 'till now I'd assumed that this was merely notional and that in real systems address spaces would be strictly n-ary trees, not graphs with cycles. Thinking it through however it's obvious that a task A can map a page P to task B which can then map it back to task A at a different virtual address. Is this allowed in L4? (I assume it is) Is it useful? Could I get away with not allowing it? I ask because my initial implementation includes a quick index from a taskid to a node in the mapping tree (to avoid recursion rather than for speed) but this requires that each task has only a single entry. Additionally, what effect should an unmap have: if task A unmaped P from task B, would the second mapping in task A disappear? I'd imagine that it would indeed remove the second mapping. I've had a look at the Fiasco souce and it wasn't clear to me where these situations are handled. Thanks. -- Martin Young, working for: | Phone: +44(0) 1454 615151 Siroyan Limited, Bristol Design Centre, | Mobile: +44(0) 7855 758771 West Point Court, Great Park Road, | web: www.siroyan.com Bradley Stoke, Bristol BS32 4QG. UK | email: my(a)siroyan.com ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

2 1

Race conditions
by Walt 07 Sep '01

07 Sep '01

Are there any papers that discuss the merits of microkernel and monolithic kernels in terms of race conditions? Regards Edsel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com

1 0

compilation errors
by rhim＠ufl.edu 05 Sep '01

05 Sep '01

Hi, while trying to compile the L4 system binaries and support servers, I ran into errors. Following is the snapshot of my system screen. --- make[2]: Entering directory `/root/Fiasco/l4/oskit/libc' gcc -c -MD -DHAVE_CONFIG_H -I. -I../libc/x86 -I../libc/stdio -I../libc/stdlib -I../libc/string -I../libc/gen -I../libc/malloc -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libc/x86/i16_bcopy.S /tmp/ccZPy7Kx.s: Assembler messages: /tmp/ccZPy7Kx.s:235: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:236: Error: `12(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:238: Error: `16(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:239: Error: `(%esi,%edx)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:242: Error: `(%edi,%edx)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:259: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:278: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:291: Error: `8(%ebp)' is not a valid 16 bit base/index expression /tmp/ccZPy7Kx.s:292: Error: `12(%ebp)' is not a valid 16 bit base/index expression ---- I am running Debian Linux 2.2.3 on pentium II on my laptop. Looking forward for help. Reagards, Himanshu

2 1

RE: L$Ka hazelnet kernel pnic
by Volkmar Uhlig 03 Sep '01

03 Sep '01

> When I boot l4ka-i586-dbg-vga (same problem happens with > l4ka-i686-rel-vga) I get a kernel panic. The message is: > startup.c:592: assertion failed (mbi->flags & MULTIBOOT_MODS) > > When I hit "k" to enter the kernel debugger, my machine > simply restarts and POSTs again, followed by my GRUB boot menu. Hi Karl, this sounds like you have problems with your version of GRUB. The error message you get is the resource manager complaining that you did not load any modules. Therefore, "k" reboots (bug/feature in RMGR) because no kernel is started yet. Try to run the ready-to-go grub image from http://i30www.ira.uka.de/~ud3/mkgrubdisk/. Volkmar PS: We try to keep L4Ka related technical problems off of l4-hackers. Please use l4ka(a)ira.uka.de instead.

1 0

L$Ka hazelnet kernel pnic
by karlm＠MIT.EDU 02 Sep '01

02 Sep '01

I downloaded the hazelnut x86 binary suite from l4ka.org I replaced lilo with grub on /dev/hda. Grub currently works fine for booting debian 2.2r3. I don't have a seperate /boot partition. My debian root partition in /dev/hda2. When I boot l4ka-i586-dbg-vga (same problem happens with l4ka-i686-rel-vga) I get a kernel panic. The message is: startup.c:592: assertion failed (mbi->flags & MULTIBOOT_MODS) When I hit "k" to enter the kernel debugger, my machine simply restarts and POSTs again, followed by my GRUB boot menu. Has anyone else experienced this? Any suggestions? I have 288 MB of RAM and a Pentium II 266 MHz CPU on a Dell Dimension XPS motherboard. All of the l4 microkernel stuff is in /boot/l4/. I copied various kernel versions over x86-kernel to see if it was a kernel version problem. rmgrlinux.cfg and glinux are identical to the files in the hazelnut x86 binaries tarball from l4Ka.org. Thanks, Karl P.S. for some reason, my menu options show empty strings in the grub boot menu. Anyone run into this, either? my grub menu.lst file reads as follows: ####### timeout = 10 default = 0 title=debian root = (hd0,1) kernel = /boot/vmlinuz root=/dev/hda2 title=L4Linux root = (hd0,1) kernel = (hd0,1)/boot/l4/rmgr -configfile -sigma0 modaddr = 0x03000000 module = (hd0,1)/boot/l4/x86-kernel module = (hd0,1)/boot/l4/sigma0 module = (hd0,1)/boot/l4/rmgrlinux.cfg module = (hd0,1)/boot/l4/glinux root=/dev/hda2 no-scroll ####### -------- Karl Alexander Magdsick PGP Fingerprint: FD9A 6DEC 0166 5331 619C D7EA 7B0C 2B90 2A83 F1FC www.keyserver.net ---------

1 0

New L4 Developer's bibliography online
by Michael Hohmuth 26 Jul '01

26 Jul '01

L4 Hackers, we have made available a new collection of L4 documentation for developers. Have a look at <URL:http://os.inf.tu-dresden.de/L4/bib.html>. This collection is meant to be platform- and kernel-implementation- agnostic. We have put in all documentation, reports, and papers we could find that could guide a developer's way through the L4 jungle. With this goal in mind, we have even added some documentation for our as-yet unreleased L4 Environment. This documentation contains many useful examples of putting L4 to use. If you have any corrections or additions, please do not hesitate to contact me. Cheers, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4-Linux as a real-time OS
by Michael Hohmuth 29 Jun '01

29 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > [...] The essential point, for my application, is that the both > types of clients must work in a single user address space, i.e. they > must be user-level threads, which are to be created through the > Linux clone() system call. Please note that currently L4Linux puts threads started by clone(...CLONE_VM...) into different L4 tasks. They will have the same memory view, but they use different address spaces as far as L4 is concerned. In other words, the L4Linux page table is shared, but L4's isn't. > In standard Linux, a process does not cause page faults once it has > invoked the mlockall() system call. It does not apply to L4Linux since > you have two different sets of page tables for an L4Linux client. One in > the Linux server, and the other in the L4 kernel. The former is filled once > mlockall() has invoked. However, the latter is left unchanged even after > mlockall() returns. Page faults are still needed just to update the page > tables in the L4 kernel. As you pointed out in the above 1, my real-time > L4Linux client must not do Linux system calls, nor page faults. There is an additional problem. Suppose your program shares pages with another process (e.g., a shared-library text segment) and the L4Linux needs to flush these page mappings for the other process. In that case, L4Linux calls l4_fpage_unmap(fpage, L4_FP_OTHER_SPACES). This call results in the shared page being flushed not only from the other task's address space, but also from your address space. You will have to remap it on page fault. I don't quite remember all cases L4Linux would have to do that, but I seem to remember that it happens when a process is killed: L4Linux needs to flush all mappings a dying task owned. As there is no way for L4Linux to tell if a task had granted away some pages, a simple task deletion is not enough; L4Linux must flush all mappings separately. For this reason (no way to prevent granting), the L4 API currently does not have a primitive for flushing a page only in a specific address space. In consequence, L4Linux needs to flush all client mappings at once. A possible extension of the L4 API would provide these two mechanisms. A possible workaround for you might be to just disable the flushing at task-delete time (Jean or Frank probably could tell you what to change), although, as I said, I don't remember if there are other places that flush mappings. > So, I made a Linux system call that makes the Linux server fill the page > tables of the calling L4Linux client in the L4 kernel. In order to implement > the Linux system call, I had to add an L4 system call, l4_fpage_map(), > which allows an L4 task (the Linux server) to send a flex page to another > L4 task (an L4Linux client) without the recipient's agreement. I believe > you do not like it because it harms the security of the system. But, being > a control system, it's still acceptable by me (may be...). You could do without the L4-kernel modification if your L4Linux system call just toggled a flag that told L4Linux to map the whole address space (l4_fpage(...L4_WHOLE_ADDRESS_SPACE...)) to the current process on page-fault. Subsequently, your client can ``forge'' a page-fault message to the L4Linux server. > >See <URL:http://os.inf.tu-dresden.de/papers_ps/part98.ps> for a > >description of the implementation. > > I failed in openning the .ps file on my system. I'll try it later again. I had no problem in downloading and opening the file, so it probably is a transient problem. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

3 2

Re: L4-Linux as a real-time OS
by Michael Hohmuth 27 Jun '01

27 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > I've been trying to use L4-Linux as a real-time platform for a control > application. [...] > 1) Is that kind of idea crazy? Not at all! > 2) Is there anyone who tried (or is going to try) something like that? We often use setups similar to the one Frank described (external L4 task doing real-time work, L4Linux runs a timesharing load) for research purposes. I am not aware of anyone who used L4Linux clients for real-time work, but the idea is interesting. I see that L4Linux clients are easier to develop and debug. However, Frank recently finished an L4-task loader for L4Linux that regains some of Linux' convenience for L4 development. > 3) Is L4-Linux going to keep up with the revisions of Linux in the > future? We certainly plan keeping L4Linux up-to-date, but I cannot make any promises. It's a matter of demand (both by ourselves and by others) and resources. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4-Linux as a real-time OS
by Michael Hohmuth 27 Jun '01

27 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > On Friday 15 June 2001 8:49 PM, Frank Mehnert wrote: > >You should not expect any real-time behavior if you use a L4Linux task > >to serve interrupts. > > Here, you mean a "process of L4Linux" by the word "L4Linux task", wright? Yes, he does. Below, I will use the term L4Linux client to avoid confusion. > >Instead of this, implement the time-critical code (e.g. I/O to VME board, > >computations of output values) in an L4 task. > > I'm aware that your suggestion is the right way. Still, it is > convenient for me if a "process" can be used to serve interrupts in > my application. I guess your "an L4 task" can be a "process" of > L4-Linux if it has a priority higher than that of the Linux server > task, am I right? I noticed that a process can cause page faults > even after it has called "mlockall" to make itself > memory-resident. I've taken care of this. You're right in principle, but there are some obstacles. 1. Obviously your real-time L4Linux client must not do Linux system calls. 2. How do you increase the L4 priority of your program? In an L4Linux client you can't because it has an MCP (maximum controlled priority) of 0. You need to implement an L4Linux driver or a program external to L4Linux (an "L4 task") to increase your client's priority. 3. As you noticed, mlockall() makes the program memory-resident, but doesn't prevent page faults: When L4Linux kills an L4Linux client, it flushes some pages from all clients' address spaces (which these clients need to map in again upon the next page fault). You said you've taken care of this problem. How? One solution would be to use an external memory manager (an L4 task) that provides nonpageable memory. > >Then you will get worst-case latencies of about 85 microseconds (P800). > > The worst-case interrupt latency I got was roughly 700 microseconds. > What dominates the latency in L4-linux is not the performance of L4 > (I'm using Fiasco, actually) but the critical sections of Linux, > which are executed with disabling interrupts. RT-linux people found > that standard Linux disables interrupts as long as 600 > microseconds. It applies to the Linux server task of L4-Linux as > well, I guess. I'm thinking of replaceing the "interrupts off" with > another method to achieve required mutual exclusion. Then, I will > get the number you suggested, hopefully. This is exactly the problem the "tamed server" option Frank recommended solves: > >Note that you should use the tamed version of L4Linux (make menuconfig - > >"L4Linux options" - "Use tamed server"). > > I'm going to check what the option does. Still, I was wondering if > you could explain the point to me. See <URL:http://os.inf.tu-dresden.de/papers_ps/part98.ps> for a description of the implementation. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Fiasco Status
by Michael Hohmuth 18 Jun '01

18 Jun '01

COFFMAN Steven <SCoffman(a)COVANSYS.com> writes: > Sorry if this was mentioned previously, but the status page for Fiasco > (October 2000) mentions that Fiasco still doesn't have Flex I/O pages. Is > this still the case with CVS? I/O flexpages still are not implemented. Unfortunately, implementing it is not a top priority for us right now (as Fiasco and L4 mostly are used in research contexts), but it still would be nice to have. The priorities could change if an external user shows significant interest. We are currently looking for a student or a contributor to implement this feature. I believe it's not that difficult to do. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

3 2

Re: Fiasco Status
by Michael Hohmuth 18 Jun '01

18 Jun '01

Christian Stueble <stueble(a)cs.uni-sb.de> writes: > I am very interested in I/O flexpages and a working clans & chiefs > concept to be able to improve the Perseus secure operating system > project. (http://www.krypt.cs.uni-sb.de/~perseus). And I have some > students here which are interested in practical jobs. But of course > they are more interested in security than in operating systems. Do > you think that it would be possible to implement this features at > the time of a software practical (about 6 month 6 h/week)? Yes, I think so. However, if your student does not have an operating-systems background, she or he needs to be willing to dive into all of the IA32 reference manual, the L4 reference manual, and the Fiasco source code, or at least keep in touch with someone who has experience with these things. There are three areas of work for Fiasco: - Memory representation of the I/O-port--access bitmap - I/O-flexpage--mapping IPC - Mapping-database support for I/O addresses On user level, at least these programs need to be adapted to use I/O flexpages: - L4Linux - RMGR > Another (maybe simpler) approach to prevent hardware access would be > to allow the RMGR to completely decide whether subtasks are allowed to > access I/O ports or not (e.g. configured in the config-file). This allows us > to implement a trusted server task which executes these operations while > enforcing a security policy. Of course this would be slower etc..... For such a protocol, simple controlled inheritance of the I/O- privilege level would suffice. However, with it it's impossible to allow privileged, unmodified Linux programs (such as the X server) to access ports. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Questions: porting, L4Linux status and performance.
by Michael Hohmuth 17 Jun '01

17 Jun '01

Martin Young <my(a)siroyan.com> writes: > I'm interested in putting L4 on a 'new' processor core [...]. Cool! Can you elaborate on why you're interested in doing this? > Is there a recommended route for doing this? I suppose that I could > either write a new implementation from scratch or port an existing one. > L4Ka looks quite attactive as it already exists for more than one > platform and it's available under the GPL. OTOH the L4/x86 reference > manual is so short that a new implementation doesn't look too daunting. > Would anybody like to guess how long either route would take? (Take the following with a grain of salt: I am the main designer and implementor of the Fiasco microkernel.) In the past, no L4 implementation has ever been reused and ported to a different architecture by a group other than the originator's. It has been the L4 gospel that it is cheaper to just do a new implementation. This has worked well so far. I estimate the cost to be somewhere between .5 and 1.5 man years, depending on the level of sophistication you want to achieve (real-time? SMP?) and the tests you have (on the x86 we have L4Linux; when L4Linux stops crashing, you're done ;-). AFAICT, one of the goals of the L4KA project is to prove that a portable L4 implementation is both possible and feasible. I believe that the L4KA hackers can put their kernel on a new architecture in a matter of weeks. However, I have no idea how approachable their source code is or whether they have any design documentation or implementation notes available. If they have something, though, I'm certain they'd be happy to share it with you. (They are actively researching microkernel portability. Maybe they'd even like to hire you!) Strictly speaking, Fiasco has been developed for x86 CPUs without special regard to portability. However, Fiasco's object-oriented design encapsulates hardware specifics as much as other subsystems. I believe that it can be refactored quite easily to support more than one architecture. Therefore, I personally would look into porting Fiasco. Of course, I'm in a better position that you are, because I am well accustomed with this beast, but I believe that Fiasco's structure is quite intelligible if you are a bit into OO design. I also have some design documentation available for the asking. I and my group would be happy to help out with our experience. That said, I believe that both options for porting an existing kernel do not take significantly shorter than just doing it yourself, given you don't know the source base. Just like developing a new system, porting a kernel requires understanding it, and that can take time. > I'm also wondering how stable L4Linux (particularly the 2.2.x kernel > version) actually is. I see on the mailing list that some simple > commands can crash the kernel, but is this typical? I don't want to run > anything large like a RH distribution but a stable kernel+bash would be > great. No, this is not typical. L4Linux is quite stable and happily boots Linux to multiuser mode and runs XFree86, Netscape, XPilot and the likes. > If I were to write or port an L4 MK I expect that initial versions > wouldn't be well optimised for my CPU architecture. In this situation > how would it's performace compare to (for example) mach?

3 2

L4-Linux as a real-time OS
by Jun-ichi Odagiri 16 Jun '01

16 Jun '01

Hello, I've been trying to use L4-Linux as a real-time platform for a control application. The application was developed based on VxWorks, but ported to Linux lately. Unfortunately, as you know, Linux allows usual processes to block a real-time process for durations of 100 ms or more. I found that a process of L4-Linux can preempt the Linux server if the process is given a priority higher than that of Linux, and can continue with its work as far as it does not call Linux for services. I actually tested it on a PC-compliant VME CPU board. Interrupt latency in the worst case was less than 1 ms, even with a disk I/O background. I'm wondering if this mailing-list accepts application related issues as well. If so, I'd like to ask you : 1) Is that kind of idea crazy? 2) Is there anyone who tried (or is going to try) something like that? 3) Is L4-Linux going to keep up with the revisions of Linux in the future? I'll appreciate any suggestion, comment and criticism. Thanks in advance. J. Odagiri

2 2

RE: L4-Linux as a real-time OS
by Sebastian Schoenberg 15 Jun '01

15 Jun '01

> > You should not expect any real-time behavior if you use a L4Linux task > to serve interrupts. Instead of this, implement the time-critical code > (e.g. I/O to VME board, computations of output values) in an L4 task. > Then let this task communicate with L4Linux by IPC (usually by using > an own thread). > > Then you will get worst-case latencies of about 85 > microseconds (P800). A quick note: This relatively high number is not due to a bad implementation of the kernel itself. It is the result of a bunch of impacts such as TLB misses, cache misses for data, code and cache misses on parsing page tables, etc... Sebastian

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers