l4-hackers October 2000

l4-hackers@os.inf.tu-dresden.de

8 participants
14 discussions

Ideas for some sample L4 root_task(s) [Learning L4].
by Farid Hajji 25 Oct '00

25 Oct '00

Hi Brent, this is what I'm planning to do next to get used to the L4-Ka interface. If you are interested, let's do this together. Basically it's about exercising misc. L4 syscalls in the root_task itself. Once we understand this, we can grab libmom and add L4 sysdeps to glibc and the Hurd. 01. map from sigma0 the kernel info page into the address space of the root_task. printf() its contents, especially its 'clock' field which is updated by the ukernel. sleep some useconds and printf clock again. [-> learn more about sigma0 rpc protocol, how to send/receive a message to/from sigma0, some memory managment issues in general and l4_sleep(). ] 02. activate some threads in root_task, and let each thread continouusly putc() a unique identifying character to the screen. look at the resulting pattern. A control thread could getc() chars from keyboard and use this char to start/stop the thread that prints this char. [-> learn about threads and scheduling.] Add a pager to a thread which just printf()s each page request, before forwarding it to sigma0. Alternatively, trap the request and handle it by mapping an own page to the requester. Finally, reclaim pages that are not needed anymore (how? and how to get notified about this condition?). [-> learn about pagers and the L4 application/pager protocol.] 03. create new (child) tasks and: * map/grant some pages * send/receive messages: short message, long message, with and without string dopes etc.. * synchronize threads via blocking l4-receive syscalls. [-> learn about messages, ipc calls.] 04. understand what rmgr really does, what its interfaces to the root_task and other tasks are (a.k.a. how to request/receive ressources from rmgr) and try to implement Okuji's idea about relocation of modules (glinux) so that we can boot glinux with vanilla GNU Grub (no modaddr). 05. Attach a root_task thread to one interrupt number (say com1, clock, keyboard or whatever) and printf/acknowledge each received interrupt. [-> Handling interrupts. Is it possible to get an interrupt that is already bound by rmgr? Hmmm... ] [-> What about chaining interrupts/events? ] Write a trivial device driver server (like sorta translator), e.g. a clock device, that gets clock interrupts and reads the clock page in the kernel to update its internal notion of time. Add protocol so that other threads/tasks can ask the time via RPC (simple message) from this clock server. [-> generalize this to device driver servers in general. Think about a Hurd abstraction to access such servers. Driver-Translators? Driver-IPC? ] 06. Grab the code of a real device driver from OSKit and try to turn it into a device driver server as in 05. 07. [...] Real world examples are located in RMGR source code, and in the sources of L4-Fiasco apps and L4Linux. I'll continue to use L4Ka right now though, simply because I can compile it without problems on my FreeBSD box ;-). Any suggestions? -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 - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Re: RH6.2 and Fiasco
by Michael Hohmuth 24 Oct '00

24 Oct '00

James, are you still having problems with Fiasco? Ißm just now catching up with my email... James Riordan <rij(a)zurich.ibm.com> writes: > Now that it is built, it crashes at boot time: > > RMGR: loading (hd1,1)/fiasco/sigma0 > RMGR: detected new-style DD-L4 > RMGR: starting (hd1,1)/fiasco/main -nokdb proto=0x10128c > > Welcome to Fiasco! > DD-L4/x86 microkernel (c) 1998 TU Dresden - Jul 13 2000 > KDB: init > L4KD -BP----------------------------------------------EIP: f00011c9 > > (hang) > > Any further suggestions? This is the kernel-debugger prompt. Have you tried typing "g" (mnemonic: Go) here? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: CVS server problems?
by Michael Hohmuth 24 Oct '00

24 Oct '00

suzukis(a)flavor1.ipc.hiroshima-u.ac.jp writes: > >did anyone tried to use flux' oskit instead of oskit10 with l4? > > I think Fiasco is (although slowly) moving from oskit to oskit10. Towards > to the newest Flux OSkit will be after it. In my previous building of Fiasco, > it was still dependent on both of oskit & oskit10. So, replacing oskit by > oskit10 seems to be long way. Is it so difficult work? No, it is not that difficult, but we haven't switched to oskit10 because of two reasons: First, the newer OSKit is GPL'd, and we have to maintain a version of Fiasco that is not under the GPL to be able to sell commercial licenses. Such licenses are one way for us to continue financing Fiasco development. That said, however, I agree that a port of Fiasco to the newer OSKit would be worthwile; the old OSKit has compilation problems with newer compilers and binutils. It just isn't an option to completely depend on it; it must be possible to compile Fiasco with older OSKit's as well. So I would like to see everything that's needed from the OSKit hidden in behind a module interface that can be implemented by either the old or the new OSKit. We just haven't got around to implement this kind of abstraction. Maybe one of you can contribute? Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: CVS server problems?
by Michael Hohmuth 24 Oct '00

24 Oct '00

L4 hackers, I'm slowly working my way up through my email archive... Sorry for not responding for so long -- I've been quite busy and had trouble keeping up with my email. Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > I was able to compile flux' oskit on FreeBSD-5.X out of the box without > any problems (using gmake, gcc-2.95.2 and binutils-2.9.1). So there is > definitely something wrong with the CVS server at Dresden :-( The CVS-server problems have finally been fixed two weeks or so ago. (Our bug-tracking database is still in trouble... The problems are due to a change in our server architectue because of stability problems with our Linux SMP server.) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

RE: first experiences with l4ka on a real pentium
by Brent Fulgham 20 Oct '00

20 Oct '00

Farid, Nice work on the BOCHS write-up. I'll have to give it a try at some point. Anyway -- I also get the endless loop when booting from GRUB. I'll have to try the Dresden binary to see if this corrects the problem. If so, we'll have to see if Okuji or Gord would be willing to add whatever changes were necessary to the main GRUB tree. Since Okuji reads this mailing list, I'm hoping he'll do so (hint, hint ;-) Thanks, -Brent

2 1

L4KA mailing list
by Uwe Dannowski 20 Oct '00

20 Oct '00

Hi L4KA users! To take L4KA-specific discussions off l4-hackers, we've set up a dedicated mailing list for L4KA. To subscribe to the list, send mail containing only the word "subscribe" (without the qoutes) in the body to l4ka-request(a)ira.uka.de . To unsubscribe send the word "unsubscribe". Posting to the list is restricted to list members. Cheers, Uwe

1 0

first experiences with l4ka on a real pentium
by Farid Hajji 19 Oct '00

19 Oct '00

Hi Brent, [I Cc-ed this to contact(a)l4ka.org and l4-hackers. L4Ka reports from other users would be great too.] > I'm curious because I get similar problems to your > description when trying to boot the L4KA kernel > on a K6-2 chip. > > However, in my case the boot process seems to work > fine as far as the initial sigma0 task starts, then > rmgr in debug mode will print an error message > (or a "Hello from RMGR" message depending on the build > I use). > > Basically, the boot fails before getting into glinux > and if rmgr and the kernel are built for debugging > they will trap the error and stop. In "runnable" > mode, I just get a soft reboot. I just tried L4Ka on a real pentium box: CPU: Pentium/P54C (199.43-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8> real memory = 134217728 (131072K bytes) I was able to boot the provided root_task template, but not glinux (yet). I booted entirely from floppy, since I can't use the hd of this production FreeBSD-box for experiments. I compiled l4ka for 586 (not 686) with kernel debugger, sigma0, rmgr and the template root_task. The first thing to do was to disable the call to the kernel debugger on startup in l4-ka/kernel/src/init.c:init() #if defined CONFIG_DEBUG_KDB_ONSTART enter_kdebug("startup"); #endif I did this because I wanted to keep the kernel debugger but I didn't found out how to use it to resume booting. 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. Trying to display the memory regions with the kernel debugger was easy. E.g. "d158fb0" shows a dump at address 00159000 which started like this: 00159000: 46 .... <after 46: ELF...> I wished the kdb was documented somewhere, not only in its sources :( The screen handling is also not perfect yet (see above with 'd' command). Dumping c200000 hangs the machine, probably because that address is outside of the physical range. After fixing LINKBASE, booting with the following menu.lst entry was successful: title=L4Ka without kernel debugger on start kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/root_task.7200000 root_task is just a hello world, followed by an endless loop. This is the contents of the screen then: ----- cut here ---------- interrupt association failed (e0044800 irq: 2) interrupt association failed (e0046000 irq: 8) sigma0_main: kernel_info_page is at 0x00107000 sigma0: map 4M page at 5800000 to 4040001 sigma0: map 4M page at 5c00000 to 4040001 sigma0: map 4M page at 6000000 to 4040001 sigma0: map 4M page at 6400000 to 4040001 sigma0: map 4M page at 6800000 to 4040001 sigma0: map 4M page at 6c00000 to 4040001 sigma0: map 4M page at 7000000 to 4040001 sigma0: map 4M page at 7400000 to 4040001 RMGR: total RAM size = 130688 KB (reported by bootloader) received 122152 KB RAM from sigma0 204 KB reserved for RMGR RMGR: attached irqs = [<!0> 1 <!2> 3 4 5 6 7 <!8> 9 a b c d e f] RMGR: loading task (fd0)/l4ka/root_task.7200000 to [0x7200000-0x7201504] RMGR: starting task (fd0)/l4ka/root_task.7200000 at entry 0x7200000 via trampoline page code 0x3140. main: started. <<<-- appears over sigma0_main: ... <<<-- due to missing screen handling. ----- cut here ------------- 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: ----- cut here -------------- sigma0_main: kernel_info_page is at 0x00107000 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 ----- cut here -------------- The last line being constantly redrawn in an (endless?) loop. 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. 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 :-). Thanks, -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 - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

3 4

RE: first experiences with l4ka on a real pentium
by Brent Fulgham 19 Oct '00

19 Oct '00

Farid, > [I Cc-ed this to contact(a)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

2 1

[Patch] Bochs with 4M superpages runs L4Ka
by Farid Hajji 19 Oct '00

19 Oct '00

Hi, [Kevin: would you please have a closer look at this patch? I'm not an x86 expert and this is at best a premature first try at it. -Thanks] the following patch: http://home.kamp.net/home/farid.hajji/l4ka-bochs/ enables 4 MB superpages in bochs. With this hack, you can boot (among others) L4Ka+root_task without problems on your favorite workstation ;-) (at least I hope so!). Please refer to the file SUPERPAGES in the patched bochs sources for a quick overview. General instructions and screen shots can be found on the above URL. BEWARE: That hack is very alpha and not tested at all! Don't rely on it too much for now. At least, it won't destroy your system, since everything is emulated in software. Bochs may be slow (it is!) but at least it's more secure than plex86 or vmware and it runs on non- intel boxes too. If you find any bugs (e.g. bochs panics()), please try to track them down and fix the sources as far as possible. It is easier than it sounds because bochs sources are very clear and because you can insert printf()s everywhere. Try this with a real processor! Thanks, -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 - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Re: Task generation & Fiasco scheduler
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > 1. I tried more than a few times to create a 'task' with the l4_task_new > system call but i couldn't. If possible, please send me some examples and > describtion on creating tasks except the L4 manuals. In order to create a new task using l4_task_new, you need to own a task-creation right first. You can get one from Rmgr using the librmgr.a library call rmgr_get_task(). After that, l4_task_new() should work. Also, please don't forget that the new task needs a pager. I'll append a simple example below. > 2. I am looking for the manager of resource CPU( scheduler ). Please guide > me that where is the scheduler and how i can change it with my algorithm. Most of it is implemented in thread_t::schedule(). Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

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 October 2000