On multi-archicture CD-ROMs:

> > Another way to make a multi-architecture CDROM is to just put each
> > architecture in a separate top-level directory and use a loopback
> > mount to make the appropriate one appear as root at runtime.

> Consider the dialogue:
> Q:	"how do you access the right architecture's binaries easily?"
> A:	"mount them via loopback on the top of the file system tree."
> of course, that begs the questions:
> "how do you invoke the right copy of the mount program, to do the mount?"
> "how do you invoke the right copy of the shell?"
> "how do you invoke the right copy of init?"

Well, you basically *have* to hack the kernel, since it's not in the habit
currently of asking where it might find /sbin/init.  The simplest approach
would be to have the kernel willing to try /sbin/init.ARCHNAME if it can't
find /sbin/init; it then becomes /sbin/init.ARCHNAME's responsibility to
loopback-mount /root.ARCHNAME over / before any of its other duties.  I
think that approach would be pretty straightforward.

The more general purpose approach would be fat binaries.  Ten-way fat binaries
are pretty unappealing, but they would be a direct solution to the CDROM
problem, where you (presumably) have enough space for that much data anyway
(in fact, ten-way fat binaries can *potentially* be smaller than ten individual
binaries by a significant amount:  assuming that the data segments *ever*
turn out to be identical between architectures, you can have a few copies of
the data segment in a fat binary rather than one per ISA).  Fat binaries are
a lot more work than modifying the code that exec's init and bulking up
/sbin/init a little.  However, they solve more problems than just getting a
multi-architecture CDROM to boot.