On Tue, 28 Sep 1999, Robert Elz wrote:

>     Date:        Tue, 28 Sep 1999 11:17:14 +1000
>     From:        Simon Burge <simonb@netbsd.org>
>     Message-ID:  <199909280117.LAA07543@balrog.supp.cpr.itg.telecom.com.au>
> 
>   | 	heh; i had thought boot_pmax like we have fsck_xxx, mount_xxx, etc...
>   | 
>   | and that's where it got upto before being moved to tech-kern.
>   | 
>   | I'm happy with the boot_<arch> idea (as long as ``_'' is a valid
>   | character in a standard cd9660 filename).  Comments from anyone else?
> 
> Could someone not consider boot/pmax boot/i386 (etc) ?
> 
> 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/*).

I'd prefer to forgo subdirectories since I don't trust the ability of my
Fcode bootblock to properly parse directory entries.  OTOH, if this is
ISO9660 fs it won't work anyway since it only groks bsdffs filesystems.

Now, presuming we really go this way and have different names for each
bootloader, how do we store a bootblock for each architecture on a single
CDROM?

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me