Date:        Tue, 28 Sep 1999 09:08:59 -0700 (PDT)
    From:        "Eduardo E. Horvath" <eeh@one-o.com>
    Message-ID:  <Pine.GSO.3.95.990928090518.25094B-100000@jericho>

  | I'd prefer to forgo subdirectories since I don't trust the ability of my
  | Fcode bootblock to properly parse directory entries.

If it isn't able to correctly parse directories, then either it is using
embedded block numbers (or something similar), or it isn't working at all.
Finding /boot requires quite a lot of filesys parsing.   If you're able
to do all of that, detecting that what you found is a directory, instead of
a file, is trivial (you have the inode already, to get the block numbers).
Beyond that it is all just more of the same (the same code repeated starting
at a different base inode).

  | OTOH, if this is
  | ISO9660 fs it won't work anyway since it only groks bsdffs filesystems.

There's no reason you can't put a ufs/ffs/bsd (call it what you like)
filesystem on a CD, I do it frequently.   This kind of technique ought to
be useful on any media that might contain useful stuff for multiple
architectures.  CDs are the obvious example, but there could be others.

It might not make a lot of sense to go to all this work for your standard
root disc - that would mean an extra several blocks of i/o for every boot
after all, ...

  | 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?

CDs seems to not have anything one would call s atandard boot method - 
certainly just reading the first blocks from the cd and executing them
isn't common (though I think that's what alphas do, more or less).
Joliet (x86 type boots) extract a pointer to a magic file which they
expect to be a floppy image (most commonly).  Suns expect the CD to have
a disklabel type label, then the boot for different architectures is
selected by the partition ('a' is not used, and conventionally contains
a 9660 format image, 'b' 'c' 'd' ... are the boot images for various
different architectures).

Just being able to find a 2nd stage boot loader in a name which
depends upon the architecture is not going to be enough to allow a CD
to be made which will boot on every system type around, there will almost
certainly be some architectures that manage to have boot styles from CD
that conflict with others.   But it will certainly allow the number of
CDs needed to be bootable on everything to become less than one per
architecture.

kre