Farid,
[I Cc-ed this to contact@l4ka.org and l4-hackers. L4Ka reports from other users would be great too.]
(I'll also CC the L4 groups)
I then had to figure out, that the LINKBASE address in l4-ka/root_task/Makefile had to be changed to a real existing physical address:
< LINKBASE=0x0c200000
LINKBASE=0x07200000
If not, the following error message appears:
RMGR: loading task (fd0)/l4ka/root_task from 0x159000_0x15a6bc to [0xc200000-0xc201504 cannot allocate page at 0xc200000 : owned by 0x89] Return reboots, "k" enters L4 kernel debugger.
Yes, I saw this as well.
So far, so good. I then tried to boot glinux with the following menu.lst entry:
title=L4Ka with glinux kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/glinux.gz -s
knowing that I don't have any linux root partition on that FreeBSD box. Anyway, I just wanted to see glinux start and no more for now. As you can see from menu.lst, I had to gzip -9 glinux to fit it on one floppy. GRUB should be able to load gzipped modules. Booting this resulted in the following output screen:
In my case, for a split second I actually did see the start of a standard Linux 2.2-series boot sequence. But it almost immediately reboot.
I didn't try anything else, because I was not able to compile Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). At least the root_task seems to work and this is very good for now. Based on root_task, L4 servers can be build, probably with flux' oskit (which compiles w/o problems on FreeBSD too!). The we can start thinking about libmom and porting the Hurd to L4Ka.
Yes, this is excellent news.
But why do you feel the OsKit is necessary? It seems that with a working L4KA it should be possible to follow the example of the hello-world template to produce servers of our own. Or perhaps it's just easier with OsKit? I must admit I haven't taken the time to master that beast :)
I can't resume tests on a real pentium right now, so I'll have to look at bochs sources to add support for 4MB superpages. This will take its time though, since I'm not an x86 expert :-).
Me neither. Luckily, I do have a second machine for working with this. Unfortunately, it's another AMD K6-2 so it may suffer from problems we don't forsee yet. But it will probably be helpful data for the L4 hackers. After all, it should work on all Intel-ish processors.
Thanks,
-Brent
I didn't try anything else, because I was not able to compile Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). At least the root_task seems to work and this is very good for now. Based on root_task, L4 servers can be build, probably with flux' oskit (which compiles w/o problems on FreeBSD too!). The we can start thinking about libmom and porting the Hurd to L4Ka.
Yes, this is excellent news.
But why do you feel the OsKit is necessary? It seems that with a working L4KA it should be possible to follow the example of the hello-world template to produce servers of our own. Or perhaps it's just easier with OsKit? I must admit I haven't taken the time to master that beast :)
Of course, the first servers would use the bare L4 IPC calls, but somewhere down the road, you'll want to access a disk and here comes OsKit to your help. The OsKit libraries provide plenty Linux and FreeBSD device drivers, filesystems etc.. You don't have to maintain this widely known codebase, as long as OsKit developers do it and the OSKit libraries are not restricted for in-kernel use only. They are plain normal libs that you would link to your L4-servers, overriding functions as necessary. It seems like a quick way to put up an OS personality.
Porting the Hurd is something else. Here the libraries are already present (glibc and all other hurdish libs.). Traditional gnumach includes some old device drivers, but that is expected to improve with oskit-mach. Porting would mean to add L4 sysdeps to glibc and to implement device drivers as user-level tasks that _may_ include code from OsKit.
We could start this right now, but there's a drawback. Without a proper abstraction layer between the Hurd components (mainly glibc) and the microkernel, the same work would have to be repeated again for each other microkernel as well. That was the reason I'm interested in libmom or a replacement thereof.
Thanks,
-Farid.
l4-hackers@os.inf.tu-dresden.de