>   How is the size of the install
> filesystem determined?  What governs its maximum size?  It's a ramdisk,
> can't some directive somewhere just say "the data only takes up this
> much space, but I want to allocate *this* much"?

It's all a hardcoded mess.

The current state of install ramdisks is that somebody got it working well
enough in the case where the size of the ramdisk contents never grow, and
it was cloned around to many different ports, with random mutations along
the way. The net result is that we have a maze of little twisty ramdisk
and miniroot and diskimage building makefiles all slightly different.

I think I posted something to tech-install a couple months back about this.

> We're supposed to be the folks who are "slow to release but we do it
> correctly".  Well, we just shot that one out the window in the case
> of sysinst on this last set of snapshots (post 1.4P).

Yep. Well, we should post the dismembered corpse of this one up at the
city gate to serve as a warning for new developers.

> 4)	fix the install kernel to be able to make use of a mfs /tmp *

I think it's either this or the ramdisk generation system adds a
parameter for the minimum free space on the ramdisk. I think we should
go with whatever takes the least space: jettisoning MFS and fixing it
in the ramdisk tool, or leaving no free room on the md0 miniroot and
always mounting a decent-sized MFS /tmp.

> [*] While we're at it, could we *please* add the NIC drivers?!?  I was

Well, we've had to start doing dual-floppy ustarfs even with the 1.4.2
i386 INSTALL kernel. Might as well put GENERIC on there now.

No one "owns" the install media stuff; that's the problem, actually.

I've more or less volunteered because I have _had_ to do some damage
control just to get things working for 19991223 and 1.4.2; and this
is the kind of makefile cleanup job I'm used to doing at work.

Todd Whitesel
toddpw @ best.com