Subject: Re: What happens when the floppy's too big?
To: Chris Tribo <>
From: Bill Studenmund <>
List: current-users
Date: 04/10/2001 17:14:37
On Tue, 10 Apr 2001, Chris Tribo wrote:

> on 3/24/01 6:04 PM, Bill Studenmund at wrote something
> like:
> > I'l admit some of this code makes me dizzy, but as long as either OF will
> > let us keep the floppy device open after we eject and insert the next
> > floppy, or we can close & re-open, we should be able to supprt mutliple
> > floppies.
>     Yes and no. You are correct that we _can_ break the install disk image
> into two parts with libsa, and "that's how multi-floppy kernels load" [on
> i386], that's not the problem. The problem is how do we re-assemble the two
> parts and execute it on macppc. This will require either:
> a.) ofwboot.{xcf,elf} to be re-written with the needed bits to copy each
> disk chunk into RAM sequentially, and then boot the resulting "RAM disk"
> image in OFW (as you suggested); or

Uhm, that's what ustarfs support in libsa is all about. :-) As I
understand how the code's supposed to work, ofwboot won't know it's
getting a file off of multiple floppies.

The one problem is that the libsa code doesn't have hooks to eject the
disks, which is needed on macs. For those of you looking at code, look in
the get_volume() routine in sys/lib/libsa/ustarfs.c in the
while(havevolume != needvolume) code block.

> b.) make a second stage booter that is loaded from ofwboot.{xcf,elf} in its
> current incarnation that has support for putting the two image chunks
> together and booting the actual compressed kernel/ramdisk.
> c.) some type of CHRP script or OFW only booter (i.e. the MacOS ROM,
> yaboot(?) )
>     For some reason, I am personally in favor of b.) because it reduces the
> amount of interaction and coding we have to do in OpenFirmware, which I'm
> sure we can agree is pretty version & machine dependent.

Please look at the existing ustarfs support. It already does the work for
us. Other than eject support, I don't see anything it's lacking for us. If
it really won't work, then we should roll something else. But I think we
should give it a shot first.


>     One could also easily argue that it would be better to have one booter
> and deal with it all in one step right in OFW.

What do you mean "deal with it all in one step right in OFW"? Make ofwboot
do the right thing? I agree with that. Writing it in FORTH? No thank

>     Is there anything else I'm missing? Am I OpenFirmware phobic?

Since we can write C code which gets executed under OpenFirmware, I don't
think it's all that bad a thing.

Take care,