Subject: Re: Hello? Test...
To: None <port-luna68k@netbsd.org>
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
List: port-luna68k
Date: 02/16/2001 10:31:46
vkulkarn@brownforces.org wrote
> Hi... I just wanted to see if this list was still active...
Oh, yes. There is at least one, here.
> The web page mentions the Luna 88k... I have two of these... one
> somewhat working, and the other I'm not sure about... it would be nice
> to have an OS for them... if not, is anyone want the hardware... if
> they're willing to come pick it up, I might be willing to give it up...
I have one also and want to have NetBSD for it. The fundamental issue
for me is the lack of rock-solid foundation for develop environment,
in specific, modern GNU toolchain for m88k.
It's definitely a huge plus that we have working OS and its source
code, but it's a bit short. It's just a 4.3BSD+NFSSRC. It's good to
consult DG-UX for reference in many aspects to make design decisions.
GCC for DG-UX seems better/modestly maintained.
DG-UX seems to have three different binary APIs. Luna88k has its own
a.out variant. No clue for XD88. Dynamic linking ELF userland is
like a pie in the sky.
The good news is I have wrote some amount of m88k kernel codes
_without_ m88k compiler. m88k pmap.c seems completed (it was
scratched from vaccum) The next step is trap.c. M88k processor
exposes memory reference pipeline to kernel, and force OS resposible
to handle condition. It's weird, cumbersome and questionable healthy
processor design evolution for long run.
Nantheless, there is a hope. The pmap.c I wrote is mostly identical
to NetBSD/i386 and it would bring a chance to have MULTIPROCESSOR.
Luna88k Mach2.5 was giant-lock OS in which only one processor
(hardwired #0) is entiled to run kernel. NetBSD/m88k should be as
good as it, probably better in the aspect.
Tohru Nishimura
Information Technology Centre
Nara Institute of Science and Technology