[[This is long. Executive summary: On a pmax, NetBSD's kernel
  is a long way away from what a pmax can boot, and __some__
  compatibilety seems like a Really Good Idea, for both
  bootstrapping now and installation later]]

cgd writes:


[[ted lemon writes:]
>> I actually went to the trouble of macrofying locore.S so that it can
>> be compiled either way - each symbol is encapsulated in a cpp macro,
>> like this:
>> [ ... ]
>
>a somewhat-good idea, to get things bootstrapped, but the long term
>goals are:
>       (1) to become completely 'native',
>        (2) to be clean.
>
>I.e. if this stuff is added now, it should be removed later.

these goals are motherhood-and-apple-pie unobjectionable.
However, they seem to ignore some pragmatic aspects about
the DECstation NetBSD port:

  (a) The vendor's bootblock cannot boot a 'native' pmax NetBSD kernel,
      only ECOFF kernels with little-endian headers. (`Native' is
      little-endian a.out with a big-endian magic number.)
  (b) There's __no__ other extant bootblocks for the pmax that can boot
      a NetBSD pmax kernel, except the binary image on Gregorio.Stanford.EDU
  (c) There's no tools available for a pmax NOT ALREADY RUNNING NETBSD
      that can safely build a fileystem on a pmax that's read-write
      mountable,  by NetBSD, on a pmax. (tools that run on, e.g.,
      x86s running NetBSD do exist, and can construct filesystems
      mountable read-write, but they probably have a very
      different idea about where the bootblock code should reside.)
  (d) pmaxes -- at least those I've seen -- tend not to have
      bootable read-write removable media (e.g., floppy drives).
  (e) There's no source available from anywhere (other than me)
      from which a  bootblock that can boot a NetBSD kernel can be
      built;  the necesary  changes  haven't yet been merged into
      __anyone__ else's source tree, that I know of. This will
      hopefully be rectified in the near future. It shouldn't
      be a long-term issue.

Given all those points, the word that comes to my mind to describe
installation of NetBSD on a pmax, _WITHOUT_ using an ecoff-format
kernel at some point, is ``insurmountable''.  Clearly it can be done,
but it's not easy. Especially if one doesn't have some other machine
running NetBSD to help out.  (And why would one care about something
as old and slow as a pmax, if one had a 486 or pentium that's as fast
or faster, and better supported by NetbSD?)

This makes me think ongoing support for building ecoff kernels (e.g.,
for installation of a binary distribution) seems _entirely_
reasonable.  The only other reasonable approach I've thought of is to
write a second-level bootstrap loader that can read and load either
ecoff or native NetBSD kernels, and to install _that_.

I really, sincerely wonder if NetBSD has been ported to any other
platform where the impedance mismatch between the vendors' OS and
native NetBSD is so great? (Not counting DOS, which is so deficient
that many master boot records capable of booting other OSes are widely
available.)