- l4-hackers - example.com Site

Re: RMGR-Extension to control I/O access
by Michael Hohmuth 22 Oct '99

22 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > That is exactly what io flex pages are designed for. Initially sigma0 > > has access to all io ports and can use io flex pages to grant port > > access to other task. If sigma0 grants access a subset of the io > > address space (adressses which are accessed by in/out instructions) > > the task gets an io permission bitmap. If sigma0 (or someone else) > > grants access to the whole io address space l4 changes the iopl so > > that any thread in this task can access any port and can even disable > > interrupts. > I understand the x86 manual in that way: i/o access is permitted only if the > tasks CPL <= IOPL _and_ if appropriated bits are set to 0. No, that´s ``or,´´ not ``and.´´ > Generally, only two new IPC messages (to the RMGR or sigma0?) are > necessary: Rmgr > 1) demandPort( port_nr, size ) > 2) releasePort( port_nr, size ) Yes, that´s right. > Does someone know, why the l4 reference manual restricts the granularity of > port access to 16 byte? No, I don´t. Maybe Jochen can shed some light on this? Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Error msg: in space.cc
by Christian Stueble 22 Oct '99

22 Oct '99

Hi, if I boot Fiasco (Mar 31 1999) on my i486 machine, I get the following error message: ---- SIGMA0: Hello! i am 80000:40000, my pager is 0:0 RMGR: Hi there! RMGR: running on L4/Pentium space.cc:179: failed assertion 'size == PAGE_SIZE' ---- What does it mean? Does Fiasco only run on a Pentium machine? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 1

Re: Question about IO-fpages
by Michael Hohmuth 22 Oct '99

22 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > I think Fiasco/L4 uses memory mapped I/O, not separated I/O? Memory-mapped I/O (that is, I/O via memory accesses in the virtual address space) and I/O via the separate 16-bit I/O address space (with in/out instructions; ``port I/O'') are completely separate from each other. It is not possible to map the port address space into the virtual memory, and that means it is not possible to replace port I/O with memory-mapped I/O. That's why, the kernel needs to support port I/O. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

A few questions
by Geoff Humphreys 20 Oct '99

20 Oct '99

Hello. I have been writing my own microkernel using ideas from L4 and other kernels. I am curious as to whether or not there would be an appreciable performance increase if the L4 system calls were split up into multiple calls. For example, the IPC call is be used to send messages, recieve messages, and to do RPC. Wouldn't it be faster if each of those were separate system calls (since it would require less if-then logic and bit manipulation)? Is there any reason not to do this? In addition, I am seeking well-commented, easy to understand scheduling algorithms or detailed descriptions of them. Right now I am using a nice, simple round-robin scheduler that doesn't even take priorities into account. It is very efficient, however. 8-) Also, does L4 have any support for semaphores? I was unable to find anything in the documentation. Thanks Geoff ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: A few questions
by Jean Wolter 20 Oct '99

20 Oct '99

"Geoff Humphreys" <xsaber0(a)hotmail.com> writes: > > Hello. I have been writing my own microkernel using ideas from L4 and other > kernels. > > I am curious as to whether or not there would be an appreciable performance > increase if the L4 system calls were split up into multiple calls. For > example, the IPC call is be used to send messages, recieve messages, and to > do RPC. Wouldn't it be faster if each of those were separate system calls > (since it would require less if-then logic and bit manipulation)? Is there > any reason not to do this? Maybe you should have a look at Jochen's micro kernel papers on our L4 page (SOSP93, SOSP95). One point was to combine the various ipc operations into one system call to reduce the number of 'kernel boundary crossings'. You add one simple if and remove an expensive switch from user to kernel and back. So this actually increases performance. > Also, does L4 have any support for semaphores? I was unable to find > anything in the documentation. There are no semaphores inside L4. All semaphores are implemented on user level. 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

Looking for L4 tutorials and documentation
by Geoff Humphreys 18 Oct '99

18 Oct '99

Hello. I am looking for L4 tutorials and documentation. I have the L4 reference manual for the 486/Pentium/Pentium pro, but I would like to find documentation with in-depth examples and benchmarks. Are such documents available, and if so, where? Thanks Geoff Humphreys ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: RMGR-Extension to control I/O access
by Jean Wolter 17 Oct '99

17 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I don´t know very much about the i386-processor and Fiasco, therefore > I would like to know if the following RMGR/Fiasco extensions are possible. > > 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission > bitmap pointer invalid) > > 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. > > 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases > the tasks CPL and/or changes the tasks I/O permission bitmap. > > ==> Task is able to access port 0x80 - 0x83. > > The main question: I don´t know if a task is able to change the CPL > or the I/O permission bitmap of another task. That is exactly what io flex pages are designed for. Initially sigma0 has access to all io ports and can use io flex pages to grant port access to other task. If sigma0 grants access a subset of the io address space (adressses which are accessed by in/out instructions) the task gets an io permission bitmap. If sigma0 (or someone else) grants access to the whole io address space l4 changes the iopl so that any thread in this task can access any port and can even disable interrupts. So the only missing feature is an implementation of io flex pages. 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

RMGR-Extension to control I/O access
by Christian Stueble 15 Oct '99

15 Oct '99

Hello, I donŽt know very much about the i386-processor and Fiasco, therefore I would like to know if the following RMGR/Fiasco extensions are possible. 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission bitmap pointer invalid) 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases the tasks CPL and/or changes the tasks I/O permission bitmap. ==> Task is able to access port 0x80 - 0x83. The main question: I donŽt know if a task is able to change the CPL or the I/O permission bitmap of another task. Ciao, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Question about IO-fpages
by Jean Wolter 15 Oct '99

15 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > It is said that always the complete IO space should be specified as > > receive fpage, why? > ? With flexpages you can map a page to an arbitrary address by specifying an according receive flex page. You are not allowed to do this with an IO-area. If someone grants you the right to access port X you can't change this to port Y by specifying a receive window in you IO address space. Therefore you have to specify your whole IO address space so that IO ports are always mapped one to one. 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

Re: Question about IO-fpages
by Christian Stueble 14 Oct '99

14 Oct '99

Am Wed, 13 Oct 1999 schrieben Sie: > Hello, > > the L4 reference manual mentions IO-fpages. Has a L4 task its own > IO address space containing IO-fpages, or maps L4 the IO-fpages > into the user memory? Ok, I found the answer at the RMGR manpage :-) > It is said that always the complete IO space should be specified as > receive fpage, why? ? Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Question about IO-fpages
by Christian Stueble 13 Oct '99

13 Oct '99

Hello, the L4 reference manual mentions IO-fpages. Has a L4 task its own IO address space containing IO-fpages, or maps L4 the IO-fpages into the user memory? It is said that always the complete IO space should be specified as receive fpage, why? Thanks, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

L4 user manual
by Christian Stueble 12 Oct '99

12 Oct '99

Hallo again, I was very enjoyed to find a L4 user manual at http://www.cse.unsw.edu.au/~disy Did I look over the link at the fiasco/L4 homepage? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Driver available?
by Michael Hohmuth 12 Oct '99

12 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > Mehnert96 and Stange96 both describe an environment to use Linux-drivers > together with L3. Is something similar available to L4/Fiasco? If yes, > where can the example implementations be found? Yes, similar frameworks have been created for a number of drivers (SCSI and ATM networking drivers come to my mind). These frameworks are more of a hackish ad-hoc nature and are in no way meant as a generic device-driver framework. These drivers (and their frameworks) have not been released publicly yet, and I don't know if there are plans to release them; I guess it would be a bit embarrasing for their authors to release them because they contain a lot of write-only, proof-of-concept code written for various research projects -- code they don't want anyone to see. ;-) Maybe these authors or my boss will bite and clarify what their stance on releasing this code is. However, and probably much more interesting to you, there is now a port of Utah university's OSKit (current snapshot 990722) to the L4/x86 and Fiasco interface. The OSKit comes with a lot of Linux and FreeBSD drivers, filesystems, and a complete IP stack that, with the help of a glue library the ``port'' consists of, just run on top of L4/x86 and Fiasco. There is a piece of news at <URL:http://os.inf.tu-dresden.de/fiasco/> about the port (look for liboskit10_support). It also tells you where to download the stuff. > Does L4-Linux directly access hardware ports? Yes, the drivers contained in L4Linux directly access I/O ports. > If yes, is it possible to prevent this behavior, e.g. by inserting a > new "virtual hardware layer"? I don't understand what you mean by ``virtual hardware layer'' and what exactly you want to do, but the answer to your question probably is yes. :) Do you want L4Linux to use drivers running in separate tasks so that it becomes possible to run L4Linux without any special hardware-access privileges? Yes, that is doable. In fact, I have been dreaming about such a setup on and off; this would make it possible to run and debug L4Linux under L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Driver available?
by Michael Hohmuth 11 Oct '99

11 Oct '99

Frank Mehnert <fm3(a)os.inf.tu-dresden.de> writes: > Unfortunately in German there is a paper that describes > an environment to port the Linux SCSI driver to L4: > > http://os.inf.tu-dresden.de/papers_ps/l4scsi.ps > > The source may be found at our CVS server. Nope, the SCSI package currently is not exported via our anonymous-CVS server... But if you want to release it, there probably is no problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Driver available?
by Christian Stueble 11 Oct '99

11 Oct '99

Hello, 1) Mehnert96 and Stange96 both describe an environment to use Linux-drivers together with L3. Is something similar available to L4/Fiasco? If yes, where can the example implementations be found? 2) Does L4-Linux directly access hardware ports? If yes, is it possible to prevent this behavior, e.g. by inserting a new "virtual hardware layer"? Ciao, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

Re: Error compiling linux22
by vhandel＠chem.vu.nl 09 Oct '99

09 Oct '99

>gcc: Internal compiler error: program cc1 got fatal signal 11 Are you overclocking ? Otherwise, you probably have a bad SIMM. You should read the GCC-SIG11 FAQ that comes with every linux distro. Ramon

3 2

Re: Error compiling linux22
by Jean Wolter 08 Oct '99

08 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I tried to compile linux22 (8.10.99) and get the following error message: > > --------------- > gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c > gcc: Internal compiler error: program cc1 got fatal signal 11 [...] > Is this a compiler specific problem? This sounds either like a hardware problem (a kernel make is a good test for the memory subsystem) or a compiler problem. Does it happen every time you try to compile this particular file? Or do you get random segmentation faults (signal 11)? Jean -- Mr. Johnson has learned the first rule of not being seen. However, he has chosen a very obvious piece of covah! Kablooey!

1 0

Error compiling linux22
by Christian Stueble 08 Oct '99

08 Oct '99

Hello, I tried to compile linux22 (8.10.99) and get the following error message: --------------- gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c gcc: Internal compiler error: program cc1 got fatal signal 11 make[3]: *** [svc.o] Error 1 make[3]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[1]: *** [_subdir_lockd] Error 2 make[1]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs' make: *** [_dir_fs] Error 2 stueble@rum:/usr/home/stueble/DA/Data/sb/linux22 > cpp: output pipe has been closed {standard input}: Assembler messages: {standard input}:1398: Warning: end of file not at end of a line; newline inserted {standard input}:1745: Warning: .stabs: Missing comma ---------------- System: gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) GNU ld version 2.9.1 (with BFD 2.9.1.0.15) Pentium 133, SuSE 6.0 Is this a compiler specific problem? -Chris- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 09 Sep '99

09 Sep '99

I wrote earlier: > David Waite <mass(a)ufl.edu> writes: > > > I have been having problems compiling Fiasco from the CVS drop I got about > > four days ago. The OSKit seems to be having problems with both the 'depend' > > files (they are actually getting some ELF binary tacked on to the end, > > although I haven't investigated why yet). Also, the gcc v2.95 has a problem > > with the assembly (reports invalid register use in the what looked to be > > linux scsi controller drivers) > > This seems to be a new problem triggered by the use of Gcc 2.95. I > currently cannot reproduce it (I'm still using older compiler versions). > [...] > Possible solutions would be to fix the old OSKit to compile with Gcc > 2.95, or maybe to implement some header files which emulate the old > OSKit's interface on top of the new one. BTW, according to the OSKit website, the new OSKit currently cannot be compiled with Gcc 2.95 or Egcs 1.x either, but must be compiled with Gcc 2.7.3, so upgrading now wouldn't fix this particular problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: GRUB network boot
by vhandel＠chem.vu.nl 02 Sep '99

02 Sep '99

>Are there instructions anywhere for how to do a network boot with >GRUB? I think there is code for it in Dresden's version of GRUB, but >not in GNU's GRUB, yet. I've just spent a few days integrating Dresden's netboot stuff into my heavily hacked version of GRUB, so I do have an idea how this works ;). The network device is called (nd). So your GRUB config could contain an entry like this: title= Netboot Linux root= (nd) kernel= /boot/vmlinuz [nfsroot options] or something similar :) Network boot works through TFTP/BOOTP. A linux HOWTO that helped me on the way is the Diskless mini-howto. You need to setup the bootp daemon on your server using a bootp configuration table, usually in /etc/bootptab. Read the diskless mini-howto and do man bootp to figure out how this works (do I need to post an example ?). Then, edit /etc/inetd.conf and uncomment the lines that look something like this: tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd Pitfall: don't forget to give tftpd the directory in which your netboot files are as a parameter. You will still need to supply the complete path of that dir in GRUB (the howto's are a bit misleading, they talk about changing the root dir and stuff like that) but otherwise you would have to supply a relative path, which GRUB does not support. Now you should be ready to netboot ! PS, I have heard from people that sometimes the linux bootp daemon doesn't work. In that case you can try running the dhcp daemon with bootp support. PPS, I think there's another pitfall -- I haven't been keeping track of the development of Dresden's GRUB, but if it's similar to the version that I have at home them it's based on an old version of GRUB, which *does not compile correctly with the new gas* !!!!!! If you recompile it on an up-to-date system, GRUB'll crash on boot. So beware. This same problem occurs with the GRUB dist from uruk.org... GNU GRUB fixes this. >This one is even more off-topic, but I'll just mention it quickly: I >tried last night to install GRUB on an 8.4 GB disc. I know you always >used to have to make sure that stage2 is in the first 540 MB of the >disc, but I naively assumed that, since this was modern hardware and >the latest version of GRUB, and the BIOS was set to LBA mode, I would >be all right. But it didn't work (something like "Disc geometry >error"). Do the old restrictions still apply, then? Was it GNU GRUB ? The last time I tried GNU GRUB (a month ago or so) LBA mode didn't work for me... while I have a mere 520MB disk, for which the BIOS DOES support LBA !!!!! On some partitions I got all kinds of weird geo errors, on others I got corrupted partition information and stuff like that. I was going to try to debug it but never actually got around to it... Ramon

2 1

Re: Chief number in TID's
by Michael Hohmuth 02 Sep '99

02 Sep '99

Marcus, I think there is a misunderstanding here -- Adam's question was why is the number of the chief task a part of the thread-id data structure (l4_threadid_t). As it would be beneficial to move from 64-bit thread ids to 32-bit thread ids on 32-bit architectures like x86 and StrongARM, Adam is looking for ways to reduce the size of the thread-id data structure, and one way to do so would be to throw out the chief number. Personally, I don't think there is a real reason to keep the chief number in the thread id except for backward compatibility and for ease of porting L4 apps to a changed ABI. L4 has inherited this data structure from L3, and I would be interested in why the chief number ended up in the thread id in the first place. Jochen? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

GRUB network boot
by Edmund GRIMLEY EVANS 02 Sep '99

02 Sep '99

Are there instructions anywhere for how to do a network boot with GRUB? I think there is code for it in Dresden's version of GRUB, but not in GNU's GRUB, yet. This one is even more off-topic, but I'll just mention it quickly: I tried last night to install GRUB on an 8.4 GB disc. I know you always used to have to make sure that stage2 is in the first 540 MB of the disc, but I naively assumed that, since this was modern hardware and the latest version of GRUB, and the BIOS was set to LBA mode, I would be all right. But it didn't work (something like "Disc geometry error"). Do the old restrictions still apply, then? Edmund

1 0

Chief number in TID's
by Adam 'WeirdArms' Wiggins 02 Sep '99

02 Sep '99

Does anyone have a 'good' reason for the chief number to be an a TID for the use of users (nothing to do with kernel internals and implimentation). Removing the chief from the TID allows 32bit TID's with a 'reasonable' number of tasks and threads per task. :) Cheers Adam

2 1

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 31 Aug '99

31 Aug '99

(I've put your bug report into our bugs database so that I won't forget about it.) David Waite <mass(a)ufl.edu> writes: > I have been having problems compiling Fiasco from the CVS drop I got about > four days ago. The OSKit seems to be having problems with both the 'depend' > files (they are actually getting some ELF binary tacked on to the end, > although I haven't investigated why yet). Also, the gcc v2.95 has a problem > with the assembly (reports invalid register use in the what looked to be > linux scsi controller drivers) This seems to be a new problem triggered by the use of Gcc 2.95. I currently cannot reproduce it (I'm still using older compiler versions). > I tried to upgrade to the newest OSKit I could find, but that didn't work > out either, because of some header files that were there before, and that > aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't > really think about that until now) We made a few bug fixes to the version of the OSKit we distribute, but we didn't add a lot of files. The main problem is that the OSKit's interface has changed a lot between releases -- all include files, for example, moved from <flux/foo.h> to <oskit/foo.h>, and all type names changed to names beginning with "oskit_" --, and some of the semantics also changed. Porting Fiasco to the new OSKit is easy enough (I once did this; the patch is somewhere in the l4-hackers archive), but because we in Dresden as a group haven't changed to the new OSKit yet, Fiasco hasn't, either. Possible solutions would be to fix the old OSKit to compile with Gcc 2.95, or maybe to implement some header files which emulate the old OSKit's interface on top of the new one. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

RE: Compiling Fiasco
by David Waite 28 Aug '99

28 Aug '99

I have been having problems compiling Fiasco from the CVS drop I got about four days ago. The OSKit seems to be having problems with both the 'depend' files (they are actually getting some ELF binary tacked on to the end, although I haven't investigated why yet). Also, the gcc v2.95 has a problem with the assembly (reports invalid register use in the what looked to be linux scsi controller drivers) I tried to upgrade to the newest OSKit I could find, but that didn't work out either, because of some header files that were there before, and that aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't really think about that until now) -David Waite

1 0