Subject: Re: Boot from CD-ROM
To: Chris G Demetriou <Chris_G_Demetriou@lagavulin.pdl.cs.cmu.edu>
From: John F. Woods <firstname.lastname@example.org>
Date: 04/12/1995 08:08:29
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.