In message <87r9jhiwgr.fsf@redmail.netbsd.org>,
Chris G. Demetriou writes:

>hard-coding the addresses of /boot is evil, and it's avoidable in many
>cases.  The alpha, for instance, didn't used to fit.  careful tuning
>of libsa, etc., and some trimming of code _made_ it fit.

Simon Burge did the same for the pmax at about the same time.  Apart
from really sick cases (x86 with `dedicated disk' to get around
BIOS-to-real-geometry mapping gotchas comes to mind) there's no real
reason to pin the blocks of a secondary bootstrap.  Just go through
the filesystem, and installboot becomes a no-op
(unless we actually change the primary bootstrap code).

>It would be a real shame to take a step backwards _again_, and moving
>/boot to /boot/<foo> would do that for the alpha, or bring it a lot
>closer to doing so.  (certainly, the LFS boot block wouldn't
>fit... and it's the one that most needs to look things up by block
>number!)

Does the LFS code used for standalone have #ifdefs analogous to the
standalone ufs.c? If it has to read the / directory to find /boot, how
much more is really needed to find /boot/alpha.boot?