From owner-freebsd-hackers Sat Sep 30 04:06:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA26019 for hackers-outgoing; Sat, 30 Sep 1995 04:06:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA26010 for ; Sat, 30 Sep 1995 04:06:19 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA31420; Sat, 30 Sep 1995 21:04:14 +1000 Date: Sat, 30 Sep 1995 21:04:14 +1000 From: Bruce Evans Message-Id: <199509301104.VAA31420@godzilla.zeta.org.au> To: jkh@time.cdrom.com, julian@ref.tfs.com Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Well folks, we've hit that wall we all knew was there and heading for >> us at 120Mph.. The GENERIC kernel has simply gotten too big to fit >> within 4MB now and no amount of paring back will deny a basic fact of >> life: >> >> To fit in all the drivers we need to cover a reasonable set >> of devices required at installation-time, we need more than >> 4MB and if we didn't need it today, we'd need it tomorrow. >> >> Now some of you will immediately go "ARGH! What about my custom >> router! What about my 4MB laptop!" and I know how you feel, so please ARGH! What about my quality control principles :-). >> don't write me 5 page impassioned letters in defense of the last of >> the 4MB users. If it were easy for us to continue to support 4MB >> installs you may rest assured that we *would*, and we have in fact >> worked very hard up to now to continue doing so for as long as it was >> humanly possible. But we all also knew that we couldn't keep doing it It's not easy, but we have barely tried to keep the kernel small. I knew of the following bloat: 1) The gzipped installation kernel. Saves space on install disks, wastes space in the running kernel. 2) Using mfs to get a temporary file system for the installation kernel. 3) 32K allocated for DMA bounce buffers, 512 bytes used. 4) 1K allocated for kernelname[], normally 8 bytes used. and a few minutes with `nm -n /kernel | less' showed the following 5) 32K statically allocated normally-unused nfs log buffer `nfsdrt'. 6) 5.5K statically allocated normally-unused nfs log buffer `nfsrtt'. 7) 48K statically allocated normally-unused matcd table `matcd_data' (enough for 16 drives!). 8) 3.5K of `struct tty's for ptys. 9) 3K statically allocated normally-unused mcd table `mcd_data' (only enough for 2 drives :-). 10) 4K statically allocated table `iso_ihead' for cd9660. 11) 4K statically allocated table `sl_softc' for slip. 12) numerous statically allocated tables in the 512 byte to 2K range. >> 8MB. We, at least, aren't saying *that*. It's still perfectly >> possible to generate a custom, stripped-down kernel that'll run on a >> 4MB box (though not very fast), you'll just have to lay your hands on >> an extra 4MB to get it through the installation. Not long ago we aimed at running stripped kernels (not very fast) in 2MB. >Jordan. >for the cdrom there should be an instal floppy with NO NETWORKING >THAT would make it smaller.. >i.e. has CDroms and disk support for all known devices >but no networking at all.. >that waythey can at least install fromthe cdrom >and make a kernel that suits them.. > you've certainly got enough room on the cdrom for 1 extra floppy image.. I think that goes too far. Perhaps nfs could be left out, saving 200K. Bruce