September 1999 - l4-hackers - example.com Site

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