Discussion on the future of floppies in 5.x and 6.x

Brooks Davis brooks at one-eyed-alien.net
Sun Jan 11 11:02:45 PST 2004


On Sun, Jan 11, 2004 at 10:27:46AM +0100, Nicolas Rachinsky wrote:
> * Dag-Erling Smørgrav <des at des.no> [2004-01-11 10:19 +0100]:
> > Paul Robinson <paul at iconoplex.co.uk> writes:
> > > Understood. I just think saying "let's get rid of floppies" is
> > > shooting a dog that happens to be near to hand because you don't like
> > > that dog, to stretch the analogy.
> > 
> > I don't think you have any idea how difficult it is (and has been for
> > a couple of years now) just to keep the install floppies alive.  The
> > kernel keeps growing, and the amount of "must-have" features (such as
> > acpi) keeps growing, and every time the boot floppies overflow we have
> > to toss out yet another driver that about a dozen people vehemently
> > tell us they can't live without.
> 
> Why not split the kernel onto 2 disks? The code to do this is already
> there and seems to work. And the people who think they absolutly need
> disks would have to deal with 4 disks, but that would be better than
> no disks.
> 
> Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is
> there a reason not to use it?

If you could make this work such that you just stuffed GENERIC and the
mfsroot onto however many floppies it takes, I think that would almost
certaintly solve re's problems with floppies (i.e. if all they had to do
when the kernel/mfsroot got too big was to bump a NUMFLOPPIES
variable.)  Sure that would suck for the floppy users, but that would
put the pain in the place where it's most likely to cause someone to
come up with some better.

Now, who wants to give this a try?

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040111/06cca017/attachment.bin


More information about the freebsd-hackers mailing list