> Adam,
> 
> thanks for the reply. I'm busy repairing the Ultrix kernel on the
> disk I tried to boot netBSD from; it keeps panicking when trying
> to add a block to the cmap for swap. I guess the ultrix
> filesystem kernel got slightly trashed by NetBSD. Or the
> disk is flaking out. Anyway...
> 

odd...netbsd is not supposed to be able to mount ultrix filesystems
read-write.

> >Ywhat bug...i'm using ultrix 4.0
> 
> ld -x -r on qdivrem.o clobbers the sybol table; the ultrix
> 4.2a ld and nm complain fiercely when they try and read 
> the resulting symbol table. Just that file so far.
> 

what is it about htis file?  is there something evil about it?

> 
> >You should be building the kernel -G0. so no GP shit is done.
> 
> That doesn't seem to be happening for me. I'll check again.
> It's quite likely I'm fighting someone else in the same research
> group who's putting 4.4BSD-Lite mk files in a (shared) /usr/share/mk.
> The kernel sources themselves seem to get compiled just fine.
> 
> >bash on the ultrix compat stuff...
> 
> Okay. I don't have the evolution of fffs/ufs at my fingertips.  I
> spose I could pester Mary Baker, who might know, but she's not in
> today.  I'd like to mount /usr so I can try more ultrix binaries, but
> I'm not even sure what kind of filesystem netBSD should be mounting
> ultrix partitions *as*.  From reading the docs you've written, I'm
> wondering whether an Ultrix "ufs" partition is really "ufs" or if it's
> ffs or what?

its called 'ufs' but in the sources it is ffs.  in the sources 'ufs'
contains code common to ffs, lfs, and mfs.

If you can't mount things it is likely the conf.c consistency problem
i mentioned...also try catting things to /dev/null....

> 
> Has anyone bothered to drop in the CSRG non-PROM console output?  The
> DEC prom console output turns off interrupts and is _painfully_ slow.
> Even 4.3-Reno had a smarter qvss output. And the framebuffers are
> essentially the same.  (I know, I'm lazy, I should look at the source.)

huh?  this is the 4.4-lite code...what other csrg stuff?

> 
> >                     i'm beating hard on the native
> >binaries problem.
> 
> 
> It's great that someone is. But I read that this is yet again a
> different a.out from the 4.4BSD a.out.  Is yet _another_ a.out variant
> really necessary?  Is this for dynamicaly linked shared libraries
> or something?

It is an a.out format standard acorss all of our architectures/ports
etc.  it simplifies our tools, it remove s the total and inexcusable
gore that appear's in 4.4 (not Lite) kern_exec.c which contains ifdefs
for every bleeping architecture.  4.4lite barely has a standard a.out.

it is not directly related to shared libraries....

later,
Adam Glass

------------------------------------------------------------------------------