- l4-hackers - example.com Site

Re: What is RMGR?
by Michael Hohmuth 10 May '99

10 May '99

°í¿µ¿õ <yuko(a)os.korea.ac.kr> writes: > Anyone know the relation between L4 and RMGR? > I cannot understand. -_- > > I want to know > 1) If L4 kernel could boot without RMGR?. RMGR is essential part of L4? Yes, and no, respectively. It is well possible to construct L4-based or Fiasco-based systems without Rmgr, and we have done so in the past. However, nowadays we always use Rmgr because it provides a very convenient way for bootstrapping a system. > 2) If it is essential module for L4, the size of L4 microkernel must > include RMGR size? Even then it probably wouldn't count because once the system is up and running, Rmgr is mostly idle. It certainly doesn't hurt the system performance because it doesn't induce a measurable load on the CPU caches. > I want to get related papers or documentation. Except for the manpage at <URL:http://os.inf.tu-dresden.de/L4/l4libman/rmgr.html>, there aren't any. Rmgr just happens to be an application everyone uses. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

GMD paper
by Adam 'WeirdArms' Wiggins 10 May '99

10 May '99

Anyone know where I can get a copy of: Jochen Liedtke: Improved Address Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces (GMD technical report) Cheers Adam

2 1

Re: New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

David Welch <david.welch(a)st-edmund-hall.oxford.ac.uk> writes: > I am having problems using the snapshot. It builds and boots > ok but as soon as I try to fork/exec another program it freezes. > > I am using a Cyrix processor (without the 4MB page extensions), > and the latest Fiasco snapshot (including the released patches) as > well as the latest L4Linux server and patches. [...] I suppose by fork/exec you mean the corresponding L4Linux system calls? If your problem is related to your CPU not having 4MB-page extensions, then there's a good chance that I will come across it this week: Other people have reported problems with non-Pentium CPUs too, so my sysadmin has organized an old 486 for me to debug Fiasco on. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4 threadid ver0 and ver1 bits
by Michael Hohmuth 10 May '99

10 May '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > I think they were seperate in the Intel for efficiency reasons, Yes, that's right: The way the bits are laid out in thread ids, it takes the kernel only one AND and one OR to compute the address of the thread control block; no shifts or lookups necessary. (Fiasco actually currently adds a shift because the kernel stack contained in the thread control blocks is larger to accommodate for the fact that higher-level languages need more stack space.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

L4 threadid ver0 and ver1 bits
by Daniel Potts 10 May '99

10 May '99

Hi, What is the precise meaning of the ver0 and ver1 bits in the L4 thread ids? Cheers, Daniel

2 3

New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

Hackers, I've made available a new Fiasco source code snapshot (990428), nicknamed version 0.6. It contains numerous bug fixes and two new features: - Long-message IPC has been implemented (but hasn't yet been tested extensively). - Jean Wolter has contributed a new stand-alone kernel debugger. It allows you to see critical kernel state on your text console. I've also released new snapshots for the L4 runtime support (required) and for our version of the OSKit, as well as a new patch for L4Linux. Please find the stuff here: ftp://ftp.inf.tu-dresden.de/pub/os/L4/fiasco/fiasco-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/oskit-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/linux-l4-981207.patch-02.gz Our admins are busy figuring out how to allow CVS access from the outside world. In the future this will allow you to access up-to-date source code without waiting for a new snapshot. Please visit <URL:http://os.inf.tu-dresden.de/fiasco/use.html> for updated build instructions. Have fun! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

kermit the frog <kermit(a)tower.com.ar> writes: > Well, what i saw is that the WHOLE directory structure changed ... and the > Makefile has a -I/home/drops (or something) which doesnt seems to be > needed since Fiasco compiles anyway ... These changes allow people working on only part of the source tree to check out (or unpack) only what they're working on and otherwise use what's been installed in /home/drops (DROPS_STDDIR in l4/Makeconf). > It would be nice to have the old dir. structure back ... (; It will get even better (read: more confusing ;) in the next snapshot: We've moved all include files to package-specific subdirectories to reduce clutter in <l4/*.h>, requiring changes to many source files (e.g., <l4/ipc.h> becomes <l4/sys/ipc.h>). We thought that indroducing some software-development guidelines now would hurt less than introducing them later. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

It looks like the Fiasco-0.6 snapshot has been sewed together with too hot a needle (thanks to Hoi-sun lee for reporting this problem). Please apply the patch appended below to make it compile. (This patch will also appear on the Fiasco ftp site as fiasco-l4-990428.patch-01.gz.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

deceit operations for clans+chiefs.
by Daniel Potts 01 May '99

01 May '99

Assume task A is the chief of task B, which is the chief of task C, which is the chief of task D. ;-) * Now, D does an ipc call to A. A successfully receives the message from D via the chiefs (C and B). * Now when A replies to this, the message first gets intercepted by B. * B sends a deceiting ipc to D with A as the virtual sender. This gets intercepted by C. * C sends a deceiting ipc to D with A as the virtual sender. This step fails (?!) due to direction preservation not holding. That is when C checks nchief on A it returns L4_NC_OUTER_CLAN, and nchief on D returns L4_NC_SAME_CLAN, which is not equal, and therefore not direction preserving. Have I got this scenario correct? Assuming that each cheif can obtain the virtual sender as part of it's ipc api. Cheers, Daniel

2 2

Re: Still missing something ...
by Michael Hohmuth 28 Apr '99

28 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Hello, thanks for always answering (im such a pain in the ... (-: > > Well, this time, after following Michael's instructions (heres a piece of > the code) : > th = l4_myself(); > printf("rmgr_init()\n"); > rmgr_init(); > printf("Hello, task: %d, thread: %d\n", th.id.task, th.id.lthread); > > sigma0.id.task = 2; > sigma0.id.lthread = 0; > > recv.id.task = rmgr_get_task(6); > recv.id.chief = th.id.task ; > recv.id.lthread = 0; > recv = l4_task_new(recv, 5, (dword_t) task+(4096*2), (dword_t)task, > sigma0); > > All i get is : 'sys_id_nearest' > > What is that ?? Argh, the library code snippet I sent you uses l4_nchief(), a binding for the sys_id_nearest system call, a call which has only been fixed recently. I really should release a new code snapshot... I'll try to do this later today (and I'll try to make the source code more accessible in order to avoid such problems in the future). For now, you can try the Fiasco patch below, or you can modify the librmgr.c file I sent you to find out its Rmgr server by querying its pager using l4_thread_ex_regs() instead of using l4_nchief() -- just change the "#if 0" in rmgr_init() to "#if 1". Sorry, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Still missing something ...
by kermit the frog 28 Apr '99

28 Apr '99

Hello, thanks for always answering (im such a pain in the ... (-: Well, this time, after following Michael's instructions (heres a piece of the code) : th = l4_myself(); printf("rmgr_init()\n"); rmgr_init(); printf("Hello, task: %d, thread: %d\n", th.id.task, th.id.lthread); sigma0.id.task = 2; sigma0.id.lthread = 0; recv.id.task = rmgr_get_task(6); recv.id.chief = th.id.task ; recv.id.lthread = 0; recv = l4_task_new(recv, 5, (dword_t) task+(4096*2), (dword_t)task, sigma0); All i get is : 'sys_id_nearest' What is that ?? Cheers. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > First of all, thanks for replying. I happen to have another problem. If i > try to create a new task, no matter what i do i always get the message > > 'KDB: task new: not chief' > > the line im using to create a task is as follows: > recv = l4_task_new(recv, 6, (dword_t) task+(4096*2), (dword_t)task, > L4_NIL_ID); > Where task is a function defined void task(void); Im asuming here that the > stack will begin , lets say to pages from the code page (task + (4096*2)). > > Am i missing something here ?? (-: Yes: In order to be allowed to create or delete a task, you must be the task's ``chief.'' When the system boots, Rmgr (task 4) is the chief of all other tasks, and thus is the only task which may create new tasks. Your task (probably task 5) initially cannot create any task. The current owner of a chief right to nonexistent tasks can transfer the right using the l4_task_new() system call. There is an Rmgr protocol message which allows tasks to request chief rights to specific tasks from Rmgr. I'll append below a library which wraps the Rmgr protocol into C bindings. With it it you can request a new chief right using the sequence: rmgr_init(); error = rmgr_get_task(number); (The library also contains functions called rmgr_task_new() and rmgr_task_new_with_prio() which lets Rmgr create a new task, but these currently don't work with Fiasco because they require long-message IPC. Long-message IPC has only been implemented recently, and I'm currently testing it; it will be included in the next release.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Yeah, that could be a solution (the loop) but, ass soon as i try to create the new task it dumps the register contents and then asks me if i want to reboot ... i guess ill have to recompile it with a different # and boot to try every new configuration ... Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ............................................................................... On Tue, 27 Apr 1999, Gernot Heiser wrote: > >>>>> "ktf" == kermit the frog <kermit(a)tower.com.ar> writes: > > ktf> Well, ive attached the source code of my program. To anser to your > ktf> question, recv is initialized to task=6; ltherad=0; i know that my program > ktf> starts with task=5 so im using the next task available. > > That doesn't guarantee that this task isn't in use (e.g. for a device > driver). I'm not sure how fiasco allocates initial tasks. You'd be > better off running a loop trying all task ids. > > Gernot > -- > Gernot Heiser ,--_|\ School of Computer Sci. & Engin. > Phone: +61 2 9385 5156 / \ The University of NSW > Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 > E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot > PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F >

1 0

Re: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Well, ive attached the source code of my program. To anser to your question, recv is initialized to task=6; ltherad=0; i know that my program starts with task=5 so im using the next task available. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Heres the thing, whenever I start 2 or more task/threads that contain some > sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to > be that all tasks/threads block forever, eventhough they have a TIMEOUT of > 4 secs, sometimes even less. I think you are seeing a bug in the timeout code which I happened to fix last week. Please try the patch appended below. I'll probably also release a new Fiasco snapshot soon. BTW, does anyone think a public CVS repository for Fiasco would be helpful? If so, please email me privately. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Am i missing something here ?
by kermit the frog 26 Apr '99

26 Apr '99

While "testing" some REALLY simple servers that I wrote I noticed something, maybe this is a bug or maybe Im plain dumb and im missing something (-; Heres the thing, whenever I start 2 or more task/threads that contain some sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to be that all tasks/threads block forever, eventhough they have a TIMEOUT of 4 secs, sometimes even less. Example for 2 tasks: Initialization stuff . . for(;;){ printf("."); /* wait 4 sec */ l4_i386_ipc_receive(L4_NIL_ID, 0, &d1, &d2, L4_IPC_TIMEOUT(0,0,255,8,0,0), &result); } In this example you have 2 tasks which do the same thing, just printf("something"); . Very simple, but they seem to block. The same thing happens if you create a new thread with l4_thread_ex_regs, and you have the same loop (for ... printf ... l4_ipc_recev) in a function, say my_thread, and send &my_thread as the EIP. Well, if you happen to remove those 'pauses' all threads/tasks seem to work just fine (although if youre printing in each of them you cant see anything (-: So thats it. Did anyone had this error ?? Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: using L4-Linux
by Michael Hohmuth 01 Apr '99

01 Apr '99

edmundo(a)rano.demon.co.uk writes: > I had it sort of running just now ... > [...] > I then had no cursor, but a shell, with which I could walk around the > file system using pwd, cd and echo *. It reboots as soon as I do > anything that involves a fork, such as ls, cat or sh. So I'll worry > about configuring X later, right? :-) > I built main and sigma0 myself under Debian 2.1, i.e. gcc 2.7.2.3 and > binutils 2.9.1.0.19a, from the sources dated 981207. Everything else > was already on grub-ext2fs-floppy from the ftp site. I compile on a > 686 machine and run Fiasco on a 486 machine. I have tried the boot floppy you sent me, and I was able to boot L4Linux into multiuser mode. However, I had to replace "glinux.gz" with my own, self-compiled L4Linux server image because the one on the boot floppy didn't contain drivers for my SCSI card. One thing you might want to try is booting a newer L4Linux binary (the one one your floppy is pretty old). I'll send you mine under separate cover. If this also doesn't work, I guess that Fiasco has a problem with 486s. Right now I cannot test this because I currently don't have a working 486, but I probably will get one the week after the next. Michael PS: I have uploaded a new grub-ext2fs-floppy.gz which contains the newest version of all binaries, including Fiasco and working configuration files. It's at <URL:ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/grub-ext2fs-floppy.gz>. -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Fiasco/OSKit-0.96 patch (was Re: "relocation truncated")
by Michael Hohmuth 27 Mar '99

27 Mar '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > Thanks for your answer. Could you show the patch you made for newer > OSKit? I'd like to see what changes are needed for different version > of OSKit. I'll append the patch below. You should only use it for informational purposes, and you shouldn't try actually applying it (I pretty sure it doesn't apply cleanly). This patch really only is a quick hack. There are many modifications involving changes to type names and include file names. Fiasco probably should be fixed not to rely on OSKit's type names so religiously. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

None
by Robert Kaiser 24 Mar '99

24 Mar '99

Hello Hackers, this might be slightly offtopic, but... I see the rmgr man-page mentions a document titled "Guidelines for implementing os servers on top of L4". Is this document available on the Web ? If so, where can I download it ? Thanks in advance Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

2 1

None
by Cervino Ulises 18 Mar '99

18 Mar '99

> Hello, im a student of comp. science in Argentina, and for my final projects > i intend to develop an OS over fiasco, so far all ive been doing is reading > about L4 and testing some things with fiasco, if someone is interested or > did something with fiasco (coded any servers or anything) id love to know. > > Thanks !!

1 0

Re: using L4-Linux
by Michael Hohmuth 17 Mar '99

17 Mar '99

edmundo(a)rano.demon.co.uk writes: > The nearest I've got to running L4-Linux so far, apparently, was by > dd-ing grub-ext2fs-floppy onto a floppy, adding "main" and "sigma0", > which I compiled myself, then booting with the following menu.lst: > > title = Linux > kernel=(fd0)/rmgr -nopentium -sigma0 > module=(fd0)/main -nokdb > module=(fd0)/sigma0 > module=(fd0)/glinux.gz root=/dev/hda2 > > The first error that I get is: > > RMGR: ERROR: while parsing config file: syntax error > at line 1, col 2 > > Does this matter? I don't know which config file it's talking about. > There's a rmgr.cfg.linux on the floppy, but I'm not booting with it, > because it made things worse when I tried using it. When you don't use a config file, Rmgr parses its command line for configuration info. Usually it skips over options starting with "-", but maybe the boot floppy contains an old Rmgr binary which doesn't. Copying a new binary (which you should find at l4/server/rmgr/src/rmgr) to the floppy should fix this problem. > At "RMGR: WARNING: there were 1 boot errors - continue?" I press > return ... > > Then I get a mixture of kernel start-up messages and L4 errors which > move too quickly for me to note them exactly. There are several > screens full of "sigma0 denies mapping", and there's a "Hmm, strange, > that shouldn't happen any more", These messages have no meaning, and they will be removed. Ignore them. ;) > and the last kernel message, before the machine reboots by itself, > is "INIT: version 2.75 booting". All quotations may be approximate. Hmm... a little bit of debugging would maybe help. Do you have a second machine available which you could connect to the first one using a null-modem cable? > I just tried it again, for about the fifth time, and it didn't get as > far this time. This time its last words were: > > Partition check: > hda: hda1 hda2 > VFS: Mounted root (ext2 filesystem) readonly. > wake_up_process: ipc failed > wake_up_process: ipc failed > wake_up_process: ipc failed > ... > wake_up_process: ipc failed These messages are also mostly informational. > Can anyone suggest what I can try next? Does anyone have this working? Well, we have... I suggest that you copy an image of your floppy using `dd' and send it to me; maybe I have overlooked something in the distribution. > I'm using the files dated 981207 and it's a 486 machine that I'm > using. (The other machines that I tried grind to a halt very early on > with "space.cc:179: failed assertion `size == PAGE_SIZE'".) This rings a familiar bell; I thought I had fixed this before -- I'll check tomorrow. > Does someone have working binaries of "main" and "sigma0" that I could > try, to see if there's something strange about my hardware? I don't think it's your hardware; it's just that we always test using Pentiums, and on i486s Fiasco cannot use 4-MB pages which may trigger a few bugs. We'll find them. ;) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 2

l4-hackers: new mailing-list policy
by Michael Hohmuth 17 Mar '99

17 Mar '99

Since a few days, the mailing list manager for l4-hackers only accepts messages sent by list members. This policy has been implemented to reduce the amount of spam. Until a few minutes ago, messages sent by non-members disappeared into a black hole. I just got bitten by this myself because my subscription address used to be different from my sender address. We have changed this now so that illegitimate senders get a bounce message. I will re-send a few of my messages which vanished into the black hole later today. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: "relocation truncated"
by Michael Hohmuth 17 Mar '99

17 Mar '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > From: edmundo(a)rano.demon.co.uk > Subject: "relocation truncated" > Date: Sun, 14 Mar 1999 12:48:47 +0000 > > > Does anyone with knowledge of x86 assembler understand this problem, > > and can they fix it? > > l4-oskit is rather old version of OSKit, and more recent version can > be compiled without such a error. I haven't compiled Fiasco with > oskit-0.97, but that will be fine, perhaps. The latest version is > available from the home page of the Flux Research Group, > http://www.cs.utah.edu/projects/flexmach/. There are a few changes necessary to compile Fiasco with the new OSKit. I have already done these changes once in a quick-and-dirty fashion, but I haven't merged them into the main trunk yet (and haven't updated them lately) because we haven't decided yet how and when we switch all our other DROPS components over to the new OSKit. Also, the new OSKit is so large that distributing a modified version of it is inconvenient; that's why we have to make sure that the latest official version fits our needs. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Re: 486/Pentium version problems
by Michael Hohmuth 17 Mar '99

17 Mar '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > Following the instructions at os.inf.tu-dresden.de/fiasco/use.html I > built Fiasco and the Hello World server worked. Excellent! Cool! > Then I tried building L4-Linux and it didn't work ... > > Then I noticed that grub-ext2fs-floppy apparently already contains > everything you need to run L4-Linux except for L4 itself. So I just > copied the fiasco "main" that I had built onto the floppy image as > supplied, hacked menu.lst a bit at random, and tried that. > > That didn't work either, but the thing that caught my attention was a > message something like this: > > RMGR: L4/Pentium ... > > I was running this on a 486. This is a misleading message that should be fixed. It only means that Rmgr is not running on L4/486, and that it *will* try to request 4-MB pages from its Sigma0 memory server. Can you give us a hint on what exectly went wrong, or where the system hung? > So my questions are: > > Do the same executables (main, rmgr, sigma0, glinux.gz) run on both 486 > and Pentium, or do different versions have to be built? They should run on both architectures. However, I haven't tested Fiasco (main) a lot on 486s, so there may be minor problems. The other programs have been tested on both Pentiums and 486s. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: implementations of L4
by Michael Hohmuth 17 Mar '99

17 Mar '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > I've been trying to find out about existing implementations of L4. > Perhaps people could correct or add to what I have discovered: > > * The original L4 by Jochen Liedtke. Written in assebler. For i486 and > i586. NOT FREE and therefore utterly useless :-) > > * L4/MIPS from Australia. Written in assembler? GNU. > > * L4/Alpha from Dresden and Australia. Written in assembler? Not yet > released but probably GNU? > > * Fiasco from Dresden. Written in C++, and designed for portabilty > rather than efficiency, but only runs on i486 and i586 at present. GNU. Fiasco hasn't really been designed for portability, even though it might serve as a model for future implementations (if someone would clean it up a bit ;). The reason it has been implemented in a high-level language is that this improves its maintainability. > * A version of L4 for x86 from Dresden written in C. I saw this > mentioned in the list archive. Is it really separate from Fiasco? No. There is no such beast. > * L4/ARM in assembler. Unfinished? I saw this in the archive, too. > > If this list could be corrected and completed, could it be put on the > L4 website, with links, as it must be what a lot of casual readers are > interested in knowing? Yes, that's right. The L4 web site at <URL:http://os.inf.tu-dresden.de/L4/> needs a major overhaul. Thanks for your suggestion. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0