- l4-hackers - example.com Site

netboot support for GRUB
by OKUJI Yoshinori 12 Jun '99

12 Jun '99

Hello, I was asked why we hadn't integrated the netboot support in the DROPS version of GRUB into GNU GRUB. That is just because we don't have the time. If the developers can adapt the code to GNU GRUB, I would be glad to merge the change with GNU GRUB. There is no GNU GRUB webpage yet, so I attach the draft below. Thanks, OKUJI ---------------------------------------------------------------------- OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> ^o-o^ http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /

1 0

latest cvs & previous snapshot are compatible ?
by suzukis＠file.phys.tohoku.ac.jp 11 Jun '99

11 Jun '99

Hello, The latest Fiasco which is available through CVS has the compatiblity with the previous snapshot (at 990428)? I've just compiled new Fiasco (main, rmgr, sigma0), sample server (hello) and L4-Linux 2.2 on my PC. I copied them into the grub-ext2-fs-floppy (thus, grub is same with that of the previous snapshot), but I could not make them work well, even hello server does not run. (Sorry, I can't report displayed message at present.) I will check some couples of the combinations among old/new kernel, old/new pager, old/new server, etc. If compiled correctly, the new programs can cooporate with old programs? suzuki

1 0

Re: L4Linux 2.2; Remote CVS
by Jean Wolter 10 Jun '99

10 Jun '99

suzukis(a)file.phys.tohoku.ac.jp writes: > ARCH := l4-mips > ---------------------------------------------------------- > > So, when I started make config, it generates the symbolic > links from the sources for MIPS. In linux/Makefile (2.0.21), > ARCH was defined as "l4-i386". Did I download anything > different from L4Linux/x86? Or I don't have to mind? There are currently two L4Linux architectures, one for x86 and the other one for MIPS (MIPS is still under development). Simply change ARCH to l4-i386 to build L4Linux for x86. 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

1 0

L4Linux 2.2; Remote CVS
by Michael Hohmuth 10 Jun '99

10 Jun '99

Hackers, we've released a port of the Linux kernel version 2.2 (available via remote CVS -- see below). It runs quite stably on L4/x86, but we have to conduct some more tests with Fiasco; that's why, we haven't released a snapshot yet. Also, we have set up read-only access to parts of our CVS repository: you can now access via CVS the latest (unstable) code of L4Linux 2.0, L4Linux 2.2, Fiasco, Rmgr (and other components of the L4 development environment), and our versions of the OSKit and GRUB. For access information, please visit <URL:http://os.inf.tu-dresden.de/drops/download.html>. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: SMP-Fiasco,Compare it with QNX
by Michael Hohmuth 09 Jun '99

09 Jun '99

"Gottfried F. Zojer" <go.enzoy(a)carinthia.com> writes: > First I was a OS/2 Programmer also using the Watcom-Compiler.For the > reason that the support of IBM was uncalculatable I tried to find > something different there I can use my Watcom skills.And I found > QNX.But it was simple to expensive for my use but I was thrilled from > it s abilities.So I will ask some question to the list in the hope of > feedback. > 1)Tried somebody to compile FIASCO with a different compiler then GNU > GCC No. I don't think that adapting the code to a different compiler would be a big problem, but so far nobody thought this to be a worthwile project. > 2)Are there any plans to support SMP or other forms to use this > kernel in High Performance Computing or Clustering. We plan to add SMP support, but haven't yet committed any resources to this project. > 3)From QNX I own the Demodisk(IAT-Internet Appliances Toolkit).Exist > something similar for FIASCO and DROPS. Not yet, but this is a good idea. Maybe later this year... ;) > 4)Tried somebody FIASCO kernel on Embedded products from AMD and > Jumptec. No; we don't have access to this hardware. But we do want to support it, and we're willing to work with anyone planning to get Fiasco going on it. Cheers, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

SMP-Fiasco,Compare it with QNX
by Gottfried F. Zojer 09 Jun '99

09 Jun '99

Hello, I m a newbie to this list and also in case of Kernel-programming. So I writing this mail with the hope that any feedback is coming. First I was a OS/2 Programmer also using the Watcom-Compiler.For the reason that the support of IBM was uncalculatable I tried to find something different there I can use my Watcom skills.And I found QNX.But it was simple to expensive for my use but I was thrilled from it s abilities.So I will ask some question to the list in the hope of feedback. 1)Tried somebody to compile FIASCO with a different compiler then GNU GCC 2)Are there any plans to support SMP or other forms to use this kernel in High Performance Computing or Clustering. 3)From QNX I own the Demodisk(IAT-Internet Appliances Toolkit).Exist something similar for FIASCO and DROPS. 4)Tried somebody FIASCO kernel on Embedded products from AMD and Jumptec. Nice greetings from Austria Gottfried F. Zojer

1 0

Re: Ein paar Fragen/Anmerkungen zur neuen Directory Struktur
by Jean Wolter 04 Jun '99

04 Jun '99

Jean Wolter <jw5(a)inf.tu-dresden.de> writes: > > Hallo, > Sorry for the German language posting, I accidently picked the wrong mailing list. 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

1 0

Ein paar Fragen/Anmerkungen zur neuen Directory Struktur
by Jean Wolter 04 Jun '99

04 Jun '99

Hallo, nachdem nun etwas Zeit für die liegen gebliebenen Arbeiten ist, habe ich versucht, das Repository zu übersetzen. Das ging natürlich nicht. Zwei Gründe: 1. Die privaten Includedirs sind nicht gesetzt (mit einem "PRIVATE_INCDIR='../include' make" kommt man ein Stück weiter). Sollen die privaten includes lokal gesetzt werden, dann müssen alle Makefiles angepaßt werden oder setzen wir das global? 2. Es gibt Unstimmigkeiten über die Lokation der L4 Headerfiles (ehemals libl4sys). Micha vermutet sie unter l4/sys/, sie liegen aber unter l4/. Was ist nun richtig und wer passt es an? 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

1 0

Re:
by Michael Hohmuth 31 May '99

31 May '99

"benben xiao" <xiaoxiaoben(a)hotmail.com> writes: > When I see fiasco kernel, I have a simple question: > I don't know > #if 0 > ... > ... > #endif > what do '0' mean there? This is a way to comment out unused code: Everything between "#if 0" and "#endif" is stripped by the preprocessor, and is ignored by the compiler. For more information about the C/C++ preprocessor, please refer to the GNU CPP manual. On most systems, you can browse it with "info cpp". The answer to your particular question is in "info cpp conditional deletion". Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Default attributes of tasks/lthreads
by Michael Hohmuth 31 May '99

31 May '99

Robert Kaiser <rob(a)sysgo.de> writes: > The question came up while writing a test suite for a microkernel > we are currently developing. It's API is not identical, but quite > similar to L4's (we would like to run L4Linux on it in the future). If your kernel's API is similar enough: Is there a chance of releasing your test suite as open source? We probably could adapt it to our implementations, and having a test suite for Fiasco and L4/x86 would be very useful. > I can certainly handle this behavior, but I was just wondering > what would be a "clean" design. From what I just learned, there > is in fact a difference between a thread being created and a thread > being re-started into a new context: In the first case, the thread's > scheduling parameters are inherited from the caller, in the latter > case, they retain whatever values they had before. So the caller > of lthread_ex_regs has to be aware of wether the thread already > exists or not. Yes, that's true. What you proposed earlier in this thread (make it possible to set scheduling parameters for not-yet-existing local threads) seems to be somewhat cleaner, but I think the current behavior isn't very difficult to handle; tasks have to keep track of thread states anyway because they manage the allocation of local thread ids themselves. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0