Re: Question about memory management in L4 Fiasco O.C + L4re
Adam Lackorzynski <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, On Mon Nov 30, 2015 at 15:33:08 +0100, Mahdi Aichouch wrote: > I have a question about the way how L4-Fiasco manages the page tables of L4 > tasks. > > I would like to know if it might happen that L4-Fiasco uses shared page > tables between multiples page directories. > For instance, let's say that two L4 tasks have access to one shared > library. Is it possible that the page tables of the shared library could be > used in both page directories. No, that won't happen. However, the kernel part (the upper part) is of course shared in all address spaces. > My second question concerns the physical memory layout of L4-Fiasco and > L4Linux. > > Below is a drawing of the physical memory layout of L4-Fiasco and L4Linux > running on a Qemu arm versatile express cortex-a9. > L4-Fiasco is configured to use 256MB. The drawing is cluttered. Maybe do not use tabs, or just some image format. > > My question is related to the physical memory L4-Fiasco where stores the > UTCBs of L4 tasks? > >From my tracing it seems that it uses the last 16MB of the physical memory > to store kernel objects. > Could you please tell me where in physical memory L4-Fiasco stores UTCBs > area. It's in the kernel's part, i.e. in those upper 16MB part. Adam > +-------------------------------------------------------------------+ > |0x6000 0000 |1.5GB |1536MB | 0MB > | | | | Module Boot Information > |0x6000 00E3 | |1536MB | > |---------------------------------|---------------|------------------| > |0x6000 1000 | | | > | | | > | Fiasco > |0x6000 1AFF | | | > |---------------------------------|---------------|------------------| > |0x6000 2000 | | | > | | | > | Fiasco > |0x6007 6FFF | | | > |---------------------------------|---------------|------------------| > |0x6009 0000 | | | > | | | > | Sigma0 > |0x6009 E177 | | | > |---------------------------------|---------------|------------------| > |0x6014 0000 | | | > | | | > | MOE > |0x6017 27AB | | | > |---------------------------------|---------------|------------------| > |0x6017 8000 | | | > | | | > | MOE > |0x6019 34AB | | | > |---------------------------------|---------------|------------------| > |0x6026 C000 | |1538MB | > | | | > | L4Linux Binary > |0x606D A394 | |1542MB | > | | | > | > | | | > | > | | | > | > |---------------------------------|---------------|------------------| > |0x6100 0000 | |1552MB | > | | | > | Bootstrap > |0x6100 F4FF | | | > |---------------------------------|---------------|------------------| > |0x6110 0000 | |1553MB | > | | | > | Modules > |0x6113 BFFF | | | > |---------------------------------|---------------|------------------| > |0x6113 C000 | |1553MB | Start of > Memory Handed to Sigma0 > | | | | > |0x6169 8000 | |1558MB | > | | | > | RAM DISK L4Linux > |0x6199 7000 | |1561MB | > |---------------------------------|---------------|------------------| > |0x61A0 0000 | |1562MB | > | | | | > | | | > | RAM L4Linux = 64MB > | | | | > |0x659F FFFF | |1627MB | > |---------------------------------|---------------|------------------| > | | | > | > | | | > | > | | | > | > | | | > | > | | | > | > | | | > | > | | | > | > |0x6EFF FFFF | |1776MB | End of > Memory Handed to Sigma0 > |---------------------------------|---------------|------------------| > |0x6F00 0000 | |1776MB | 240MB > | | | | memory reserved for L4 Fiasco kernel > |0x6FFF FFFF |1.75GB |1792MB | 256MB > +------------------------------------------------------------------+ > > > > > > On Fri, Nov 20, 2015 at 4:00 PM, Mahdi Aichouch <[email protected]> wrote: > > > Hello Adam, > > > > The UTCB is allocated as a physical memory page, which is a 4KB if a small > > page is used, right? > > > > Do you think that it is possible to allocated a 16KB or 32KB UTCB area, > > and to align their physical start address on 16KB or 32KB? > > > > Thank you in advance for your answer. > > > > Best regards, > > > > Mahdi > > > > > > On Mon, Oct 26, 2015 at 10:24 AM, Mahdi Aichouch <[email protected]> > > wrote: > > > >> Hello Adam, > >> > >> I have a question about the UTCB area. > >> If I understand correctly, the UTCB is physical memory page that is > >> allocated in the kernel physical memory space, then mapped into the user > >> and kernel virtual memory space, right? > >> > >> Thank you very much for your answer. > >> > >> Best regards, > >> Mahdi > >> > >> > >> On Wed, Oct 7, 2015 at 3:42 PM, Mahdi Aichouch <[email protected]> > >> wrote: > >> > >>> Hello Adam, > >>> > >>> In order to be sure that I correctly understand how Dataspace and Memory > >>> Allocator work, I tried an example where Dataspace are created using the > >>> "L4Re::Mem_alloc::Continuous and L4Re::Mem_alloc::Pinned" flags. This will > >>> ensure that the allocated physical memory is contiguous and can not be > >>> moved, right? > >>> > >>> My second question concerns the way how an L4 task is loaded into > >>> memory. Do you think that it is possible to make all segments of an L4 user > >>> program to be adjacent in physical memory. As an example, given one L4 user > >>> program we would like to have the following configuration: > >>> > >>> Physical memory > >>> > >>> 0x000000 0MB > >>> > >>> 0x100000 1MB > >>> text > >>> 0x200000 2MB > >>> data > >>> 0x300000 3MB > >>> stack > >>> 0x400000 4MB > >>> heap > >>> 0x500000 5MB > >>> > >>> (the memory addresses are given here for illustration purpose) > >>> > >>> From my tracing of Moe, L4re and libloader using Moe::Dataspace::phys( ) > >>> function, I saw that some areas were adjacent and other were not. Could > >>> you please give an explanation of how Moe and l4re load a user program from > >>> a disk into memory. > >>> > >>> Thank you very much in advance. > >>> > >>> kind regards, > >>> Mahdi > >>> > >>> > >>> On Mon, Sep 28, 2015 at 10:44 AM, Mahdi Aichouch <[email protected]> > >>> wrote: > >>> > >>>> Hello Adam, > >>>> > >>>> > An application is typically composed of multiple memory regions in > >>>> > virtual memory. Do you mean you want all those regions to be physically > >>>> > contiguous, such as text-segment, bss and stacks? This should be > >>>> > possible by using a memory allocator that makes sure this is the case. > >>>> > However, currently, there is only the possibility to have dataspaces > >>>> > physicall contiguous. > >>>> > >>>> This exactly what I mean, that is, text-segment, bss, data, stack, and > >>>> heap regions have to be contiguously allocated for Fiasco kernel, sigma0, > >>>> moe, L4Linux, and for each created L4 task. > >>>> My use case requires that each created L4 task has to be provided with > >>>> a static fixed physical memory segment, and cannot exceed its allocated > >>>> memory segment. > >>>> > >>>> Currently the memory allocator is present in moe package, right? > >>>> Thus, a new memory allocator should to be added to that package I > >>>> guess, right? > >>>> If not, could you please suggest a place in the code base where a new > >>>> memory allocator has to be added. > >>>> > >>>> I would like to implement a mechanism that allow to know for each > >>>> created L4 task which physical frame a virtual page is mapped to. The > >>>> functionality provided by such a service are similar to > >>>> pagemap [1] service in Linux kernel. > >>>> > >>>> Is such a service could be implemented at userspace in L4re? > >>>> Does Fiasco O.C provide the necessary mechanism to implement it? > >>>> If yes, could you please suggest a set functions that should be used. > >>>> > >>>> Thank you very much for your answer. > >>>> Best regards, > >>>> > >>>> Mahdi > >>>> > >>>> [1] https://www.kernel.org/doc/Documentation/vm/pagemap.txt > >>>> > >>>> On Wed, Sep 16, 2015 at 11:45 AM, Mahdi Aichouch <[email protected]> > >>>> wrote: > >>>> > >>>>> Hello Adam, > >>>>> > >>>>> I updated the schema of the memory mapping of L4Linux and Fiasco O.C > >>>>> according to your corrections. > >>>>> Could you please take a look at it and tell me if everything is > >>>>> correct. > >>>>> > >>>>> I have some questions about the way Fiasco O.C µ-kernel loads the L4 > >>>>> tasks into physical memory. > >>>>> > >>>>> If I correctly understood, when Fiasco O.C creates a new L4 task it > >>>>> uses a copy-on-write > >>>>> mechanism to allocate physical pages in memory, right? > >>>>> That means, the physical memory region allocated to an L4 task might > >>>>> not be formed > >>>>> by a contiguous set of physical pages. > >>>>> > >>>>> Is it possible to make Fiasco O.C reserves a physical memory region > >>>>> composed by a > >>>>> set of contiguous physical memory pages when creating an L4 task? > >>>>> > >>>>> If the answer is yes, could you please suggest an example showing the > >>>>> way to do it. > >>>>> > >>>>> My second question concerns the L4Linux tasks. Could you please tell > >>>>> me some > >>>>> explanation about the way L4Linux and Fiasco O.C load into physical > >>>>> memory the L4Linux tasks, > >>>>> and where can I find the code that is doing these operations. > >>>>> > >>>>> Thank you very much in advance. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Mahdi > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Sep 9, 2015 at 3:28 PM, Mahdi Aichouch <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> Hello Adam, > >>>>>> > >>>>>> In order to document my investigation of memory management in L4Linux, > >>>>>> I draw an abstract representation of the memory mapping of L4Linux's > >>>>>> tasks > >>>>>> virtual memory into L4Linux "real" memory and into physical memory. > >>>>>> > >>>>>> Could you please take a look at my schema and tell if it correctly > >>>>>> represents > >>>>>> the memory mapping in L4Linux. > >>>>>> > >>>>>> Any corrections and remarks are welcome. > >>>>>> > >>>>>> Thank you very much in advance. > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Mahdi > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jul 31, 2015 at 5:03 PM, Mahdi Aichouch <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> Hello Adam, > >>>>>>> > >>>>>>> Is it possible to know where a UTCB memory area is allocated in the > >>>>>>> physical memory space of a thread. > >>>>>>> If the answer is yes, could you please suggest a way to do it. > >>>>>>> > >>>>>>> Thank you very much for your answer. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Mahdi > >>>>>>> > >>>>>>> On Tue, Jul 28, 2015 at 4:10 PM, Mahdi Aichouch <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Hello Adam, > >>>>>>>> > >>>>>>>> I have a question about the way Fiasco.OC handles IPC. > >>>>>>>> > >>>>>>>> If we take a simple example of one thread in address space A that > >>>>>>>> sends an array of characters to a second > >>>>>>>> thread located in an address space B. > >>>>>>>> Since such an array might be large and cannot be transferred using > >>>>>>>> the registers. > >>>>>>>> > >>>>>>>> How it is transferred to the second thread address space? > >>>>>>>> > >>>>>>>> Is it at first allocated on the first thread stack, then copied by > >>>>>>>> Fiasco kernel to > >>>>>>>> the second thread address space? > >>>>>>>> > >>>>>>>> Thank you very much for your answer. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Mahdi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Jul 24, 2015 at 9:12 AM, Mahdi Aichouch <[email protected] > >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>>> Hello Adam, > >>>>>>>>> > >>>>>>>>> What I mean by accessing memory partition is: does Fiasco.OC > >>>>>>>>> accesses memory > >>>>>>>>> reserved for L4Linux when handling system-call issued by L4Linux > >>>>>>>>> guest for example > >>>>>>>>> or any other operation. > >>>>>>>>> > >>>>>>>>> Thank you very much for your answer. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Mahdi > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Jul 23, 2015 at 5:32 PM, Mahdi Aichouch < > >>>>>>>>> [email protected]> wrote: > >>>>>>>>> > >>>>>>>>>> Hello Adam, > >>>>>>>>>> > >>>>>>>>>> I would like to know if Fiasco.OC kernel accesses memory > >>>>>>>>>> partition allocated to an L4Linux guest? > >>>>>>>>>> And for what reasons it has to do it? > >>>>>>>>>> > >>>>>>>>>> Thank you very much for your answer. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Mahdi > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Wed, Jul 22, 2015 at 3:19 PM, Mahdi Aichouch < > >>>>>>>>>> [email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hello Adam, > >>>>>>>>>>> > >>>>>>>>>>> According to Fiasco O.C/L4re documentation Sigma0 is the root > >>>>>>>>>>> pager, > >>>>>>>>>>> that is, it is responsible of resolving page fault of user-level > >>>>>>>>>>> tasks, right? > >>>>>>>>>>> > >>>>>>>>>>> Knowing that L4Linux is created as a user-level task, thus any > >>>>>>>>>>> memory page fault occurring > >>>>>>>>>>> in L4Linux or its user processes logically has to be handled > >>>>>>>>>>> through Sigma0. > >>>>>>>>>>> > >>>>>>>>>>> However, as you previously mentioned in one of your answers, a > >>>>>>>>>>> handling of > >>>>>>>>>>> a page fault occurring in L4Linux does not involve any L4Re > >>>>>>>>>>> object including Sigma0. > >>>>>>>>>>> > >>>>>>>>>>> My question is: what configuration and / or operations have been > >>>>>>>>>>> made > >>>>>>>>>>> in order to force that a memory page fault in L4Linux has to be > >>>>>>>>>>> handled > >>>>>>>>>>> only by Fiasco and L4Linux and not going through L4Re objects? > >>>>>>>>>>> And where these operations are written in the source code. > >>>>>>>>>>> > >>>>>>>>>>> Thank you very much for your answer. > >>>>>>>>>>> > >>>>>>>>>>> Best regards. > >>>>>>>>>>> Mahdi > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Jul 21, 2015 at 4:06 PM, Mahdi Aichouch < > >>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hello Adam, > >>>>>>>>>>>> > >>>>>>>>>>>> I would like to understand how L4 Fiasco manages the virtual > >>>>>>>>>>>> memory of a L4Linux guest. > >>>>>>>>>>>> > >>>>>>>>>>>> Does L4 Fiasco maintains a "shadow page table" in order to > >>>>>>>>>>>> perform a two-level memory address translation: > >>>>>>>>>>>> guest virtual memory --> guest real memory --> host physical > >>>>>>>>>>>> memory? > >>>>>>>>>>>> > >>>>>>>>>>>> If the answer is yes, where the "shadow page table" is > >>>>>>>>>>>> maintained? which L4 Fiasco object > >>>>>>>>>>>> is responsible of this operation? > >>>>>>>>>>>> > >>>>>>>>>>>> If we suppose that an L4Linux guest has for example a 64MB of > >>>>>>>>>>>> fixed physical memory region, > >>>>>>>>>>>> in case a new L4Linux user task arrives and there is no > >>>>>>>>>>>> available space to allocate > >>>>>>>>>>>> a new page for this task, an already used page has to be > >>>>>>>>>>>> unmapped, right? > >>>>>>>>>>>> > >>>>>>>>>>>> If the answer is yes, then where the dirty page will be swapped? > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you very much for your answer. > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Mahdi > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Jul 20, 2015 at 4:36 PM, Mahdi Aichouch < > >>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hello Adam, > >>>>>>>>>>>>> > >>>>>>>>>>>>> If I correctly understood, and If we suppose that an L4Linux > >>>>>>>>>>>>> instance > >>>>>>>>>>>>> is started for example with this command line options: > >>>>>>>>>>>>> ... earlyprintk=1 em=64M ... > >>>>>>>>>>>>> > >>>>>>>>>>>>> This means that a 64MB of physical memory region composed of a > >>>>>>>>>>>>> set of contiguous physical frames is allocated to L4Linux, right? > >>>>>>>>>>>>> > >>>>>>>>>>>>> L4Linux will use a part of this 64MB of physical memrory for > >>>>>>>>>>>>> its own kernel execution, and > >>>>>>>>>>>>> the rest of physical memory space will be used by L4Linux to > >>>>>>>>>>>>> load user-level programs > >>>>>>>>>>>>> and allocate physical memory for them, right? > >>>>>>>>>>>>> > >>>>>>>>>>>>> If a user-level program on top of L4Linux generates a > >>>>>>>>>>>>> page-fault. > >>>>>>>>>>>>> Are the L4 Fiasco kernel and L4re involved in the execution > >>>>>>>>>>>>> flow to handle the page-fault? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you very much for your clarification. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Mahdi > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, Jul 17, 2015 at 10:36 AM, Mahdi Aichouch < > >>>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hello Adam, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The memory regions are exclusive. Specifying exactly which physical > >>>>>>>>>>>>>>> memory an L4Linux is getting is currently not possible but I guess > >>>>>>>>>>>>>>> you're using the numbers just as an example? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes, I am giving these numbers as an example. > >>>>>>>>>>>>>> However, is it possible to know what are the start address and the end address > >>>>>>>>>>>>>> of a physical memory partition allocated to a L4Linux instance? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The memory is completely mapped initially, so no page fault should > >>>>>>>>>>>>>>> happen. As probably nobody will take it away again it should also stay > >>>>>>>>>>>>>>> like this. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does this apply also to user-level programs executed on top of L4Linux. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> You can put showpfexc=1 on the cmdline to see any in-kernel page fault. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> There shouldn't be any (except in the outside wrapper code as I see > >>>>>>>>>>>>>>> which can be changed by launching L4Linux with the eager_map flag). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Could please give some explanation about what is the wrapper code? And Where to set the "eager_map flag" option? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you very much for your answer! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Mahdi > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Jul 15, 2015 at 11:53 AM, Mahdi Aichouch < > >>>>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hello, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have some questions concerning memory management in Fiasco > >>>>>>>>>>>>>>> O.C + L4re. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I would like to test two L4Linux instances, and for each > >>>>>>>>>>>>>>> L4Linux > >>>>>>>>>>>>>>> instance I want to reserve one static fixed physical memory > >>>>>>>>>>>>>>> partition. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> For instance, one 128MB for the first L4Linux and one 128MB > >>>>>>>>>>>>>>> for the second. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Knowing that Fiasco O.C. uses "on demand paging" to allocate > >>>>>>>>>>>>>>> pages for > >>>>>>>>>>>>>>> user tasks, is it possible that each partition of L4Linux > >>>>>>>>>>>>>>> could be allocated > >>>>>>>>>>>>>>> a static physical memory region composed of contiguous > >>>>>>>>>>>>>>> physical frames. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> For instance, one memory region starting from 128MB to 256MB > >>>>>>>>>>>>>>> for the first L4Linux, > >>>>>>>>>>>>>>> and second memory region from 256MB to 512MB for the second > >>>>>>>>>>>>>>> L4Linux. > >>>>>>>>>>>>>>> Each memory region is allocated exclusively to one L4Linux > >>>>>>>>>>>>>>> instance. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I would like to know if it is possible to load all the code > >>>>>>>>>>>>>>> + data of a L4Linux instance > >>>>>>>>>>>>>>> into its reserved memory partition, so no page fault will be > >>>>>>>>>>>>>>> encountered during runtime. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Is it possible to tell me if these above operations could be > >>>>>>>>>>>>>>> realized in Fiasco O.C and L4re? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If the answer is yes, is it possible to tell me what are the > >>>>>>>>>>>>>>> objects that should be used or > >>>>>>>>>>>>>>> adapted in order to implement these? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What are the issues that I should pay attention to? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Many thanks in advance for your answer. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Mahdi > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > _______________________________________________ > l4-hackers mailing list > [email protected] > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers -- Adam [email protected] Lackorzynski http://os.inf.tu-dresden.de/~adam/