Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA23558; Sat, 30 Sep 95 07:11:18 EDT
Received: from freefall.FreeBSD.ORG by MIT.EDU with SMTP
	id AA29446; Sat, 30 Sep 95 07:10:51 EDT
Received: from localhost (daemon@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA26081
          ; Sat, 30 Sep 1995 04:08:11 -0700
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 <hackers@freefall.freebsd.org>; 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 <bde@zeta.org.au>
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
