l4-hackers

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

2 participants
2880 discussions

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

MIPS
by Gottfried F. Zojer 28 Aug '99

28 Aug '99

Hi, I m sending this posting to find out how many are using Fiasco/L4 on Mips-Processors. And I hope that there is coming in some response. Sincerely Gottfried F. Zojer

2 1

Re: NT like OS's
by Tom Linden 27 Aug '99

27 Aug '99

Are you sure you want to do this? What about all the dll's? I think it advisable to set down goals and functioanl specs before embarking on such an adventure. I also think that you should look at all the opportunities including L4-Linux from Dresden. <l3-hackers(a)os.inf.tu-dresden.de> I also have a mature, fault-tolerant operating system, originally written for IBM mainframe, which is quite portable. Hadn't planned on porting it to alpha, but it is a possibility, particularly since later alphas understand Big Endian. On Fri, 27 Aug 1999, Peter Lizon wrote: > Date: Fri, 27 Aug 1999 12:58:34 -0400 > From: Peter Lizon <peter(a)alphant.com> > To: AlphaNT Mail List <AlphaNT(a)AlphaNT.com> > Subject: Re: NT like OS's > > Yeah - this is what I was looking for, not OpenNT . . . Now can we port this > to Alpha please? Preferably by the end of the year ;) > > Peter Lizon > ----- Original Message ----- > From: Michael Rich <istan(a)alltel.net> > To: <alphant(a)alphant.com> > Sent: Friday, August 27, 1999 12:38 PM > Subject: NT like OS's > > > > I know its off the wall, but there is at least one project thats currently > > working towards an NT compatible system. Currently its only x86 > > unfortuantly, but its open source, so anyone could start work on a > different > > processor. > > > > http://www.reactos.com > > > > Michael Rich > > http://alphax86dev.cjb.net > > > > __________________________________________________ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ /_/ /_/ /_/ Tom Linden PL/I Support /_/ /_/ Kednos Corporation OpenVMS and /_/ /_/ tel 650 566 9484 Tru64 Unix /_/ /_/_____________________________________________/_/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 27 Aug '99

27 Aug '99

I wrote: > edmundo(a)rano.demon.co.uk writes: > > > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > > several times. > > I can reproduce this: Under heavy interrupt load, a thread's kernel > stack can overflow on slow machines. I'm still thinking about what > the best way is to correct the problem. I think I found a solution to this problem. I've checked it in. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 26 Aug '99

26 Aug '99

edmundo(a)rano.demon.co.uk writes: > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > several times. I can reproduce this: Under heavy interrupt load, a thread's kernel stack can overflow on slow machines. I'm still thinking about what the best way is to correct the problem. > (2) Frequently cc1 segfaults when compiling a large file. Annoyingly, > it hasn't done it since I built one with debugging symbols. Maybe this is a symptom of an undetected kernel-stack overflow: When the kernel accidentally touches user memory, this can lead to page-fault messages being sent to the thread's pager and the thread being killed. > (3) The following C code causes massive strafing[1] of the disc which > I can terminate only by rebooting as the process seems to ignore all > signals. > > { > unsigned char a[4096*1024]; > int i; > unsigned char c; > > for (c = 0; ; c++) { > for (i = 0; i < sizeof(a); i += 4096) > a[i] = c; > } > } > > On one occasion cc1 gave the same behaviour. > > Can anyone tell me if this behaviour is a bug? It might just be a > "limitation" of L4-Linux, in which I'm in trouble, because it's the > only nasty behaviour which I can reproduce in a simple way. > > I only have 8 MB of memory, by the way, so the code above is expected > to exercise the disc. I just don't expect it to be unkillable. A > program that mallocs lots of 4000-byte blocks doesn't become > unkillable in the same way. I'd say the unkillable process is a bug, but the disk thrashing is to be expected on a low-memory machine. I'll try reproducing this later -- I'll tackle the stack-overflow problem first. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Porting Hurd to l4
by Michael Hohmuth 25 Aug '99

25 Aug '99

Matthew Vernon <matthew(a)debian.org> writes: > Is the l4 server interface descripted somewhere (as in, I need a > little more help getting started than just RTFsource :) )? I guess you mean the L4-kernel interface to be used by servers, don't you? This interface is documented in manpages at <URL:http://os.inf.tu-dresden.de/L4/l4man.html> (this is for Fiasco and L4/x86; the L4/MIPS website has manpages for the MIPS version). The L4 Reference Manual is the defining document for the L4 API (and x86 ABI); it's available at <URL:http://os.inf.tu-dresden.de/L4/l4refx86.ps.gz>. > I'm beginning to think the effort involved in porting the HURD > servers to Mach may be worthwhile in the long run. ^^^^ L4? If the Hurd wouldn't be too Mach-dependent, and would instead use a microkernel-independent object model (like "MOM", a framework Bryan Form from Utah was thinking about at one point), it should be possible to port it to L4. In fact, if you look closely, there is even some (unused and orphaned) early support for MOM in the Hurd source tree (in the libmom directory). Then, all you would need for a port to L4 would be an object framework (something like a server supporting a slim version of Mach ports) and a set of device drivers. Personally, I'd love to see a Hurd port to L4. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Jump to page:

2025

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