> >I'm working on a port of NetBSD to a big-endian mips system, using
> >the pmax port as a starting point, and I'm a little confused by
> >the way dynamic loading is handled.
> 
> In general, the pmax port is a bad model to emulate. 
> If you're doing a mipseb port, then contacting the newsmips people is
> probably a good idea.  They're actively working on better, cleaner
> code for SPLs, for machines which dont have all the weird DEC
> motherboard interrupt-control registers.

We actually have a very simple device model, so cleaning things up should
mostly be a matter of ripping out stuff.  However, I wish I'd started
this project a few years earlier when my Sony News 3250 still booted
;-)  I had assumed the NEWS stuff was dead since the code had dropped
out of the netbsd ship tree.

I have a bare-bones mipseb kernel running in simulation using the Stanford
SimOS simulator.  I hacked together a pseudo console and network device,
and the machine gets all its files via NFS.  It might be a useful tool
for tracking down odd kernel problems, since it can be easily instrumented.

> "in a couple of days". The mips port of ld.elf_so is completed, is in
> use on developer's systems, on both big and little endian, and should
> be in the tree within days.  Early access can be arranged.

Sounds very cool.  

> The only remanining niggle is that the exising ld.elf_so has never
> really been MI.  It contains a fair bit of alpha-specific hair, like
> 64-bit-ness and Alpha-specific relocs. We're waiting for feedback on
> how best to clean those up, or if (for now) inline ifdefs are
> acceptable.

Of course, the mips stuff could eventually be 64-bit, right?

> >I would guess it's actually the OpenBSD loader from looking at the bits,
> >but I don't see that in the source tree.
> 
> Not quite, they're both slightly different versions of (an older
> release of) the GNU glibc ld.so.

Thanks for all the feedback! I'm looking forward to putting more of this
stuff together, soon.

	-castor