- l4-hackers - example.com Site

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