Robert Elz <kre@munnari.OZ.AU> writes:
> Could someone not consider boot/pmax boot/i386 (etc) ?

Please, no...


> For systems whose first stage boot has block numbers built in, this makes
> no difference at all to anything.   For those that actually do a lookup of
> "/boot" (or /boot_pmax or /boot/pmax or whatever is selected), using the
> directory method should provide much better compatability and simplicity, the
> first stage boot can just look for /boot first, if that turns out to be
> a directory rather than a file, then append the arch and loop back and
> repeat the lookup.   Just an extra couple of lines to allow support of
> both single arch boot (/boot) and multi-arch (/boot/*).

To quote simonb:

>Currently the alpha bootblocks are compiled such that the libsa ufs.c
>doesn't descend into directories.  Adding the directory descent stuff to
>my test pmax code (based on the current alpha bootblocks) added another
>176 bytes to the total size of the first stage bootblocks.  Adding the
>check for "boot/pmax" then "boot" chewed another 64 bytes.  There's
>still another 304 bytes left over.  Heaps :-)

The alpha isn't quite so lucky:

with -DLIBSA_FS_SINGLECOMPONENT (i.e. only files in / supported):

-rw-r--r--  1 root  wheel  6888 Sep 28 20:55 bootxx_ffs

without:

-rw-r--r--  1 root  wheel  7496 Sep 28 20:57 bootxx_ffs


The limit is 7680.  If you add in code to check for a file in two
places, you'll need that, which'll push you over the edge, plus the FS
close code (rather than some hacked up close code) which'll put you
further over the edge, ...

Also, the LFS boot block is already a few hundred bytes closer to the
limit than the FFS boot block, iirc.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.