From owner-freebsd-hackers  Mon Oct  2 05:26:12 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id FAA14848
          for hackers-outgoing; Mon, 2 Oct 1995 05:26:12 -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 FAA14828
          for <hackers@freefall.freebsd.org>; Mon, 2 Oct 1995 05:26:03 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA26089; Mon, 2 Oct 1995 22:24:11 +1000
Date: Mon, 2 Oct 1995 22:24:11 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510021224.WAA26089@godzilla.zeta.org.au>
To: bde@zeta.org.au, julian@ref.tfs.com
Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation.
Cc: davidg@Root.COM, hackers@freefall.freebsd.org, jkh@time.cdrom.com
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>> Surely there is more of a problem fitting everything at runtime than just
>> loading it?
>The limiting factor is either fitting the compressed file between
>3MB and the end of RAM, or fitting the output of the decompression
>between 1MB and 3MB.. I've seen both fail at various times..

The packing problem could be reduced by keeping the mfsroot in a separate
file or on a separate floppy, but these methods are currently too hard,
and if we go to a separate floppy we might as well forget about compression
(at least while the kernel and the mfs still fit on a 1200K floppy).

>You could relocate the decomp routines to < 640K and run them down there
>and let the decompressed output overwrite the start of the compressed version
>(and hope it never catches up with the read pointer..)

>I think the problem at the moment is htat the compressed binary runs
>past 4MB.

Relocation of code would be messy.  Relocation of data is easy.  If the
last problem is the only one, solve it by copying the last few hundred K
of the compressed binary to low memory while you're decompressing the
first few hundred K, then put it back.  This could be combined with
overwriting to increase the chance that the write pointer never catches
up.

The current memory map at decompress_kernel() time seems to be:

	0: reserved
	4K: free
	64K: boot program (need to preserve a little of its data)
	128K: free
	320K: malloc heap
	nnnK: end of low RAM; start of memory abused by malloc if nnn < 640
	640K: bus memory

There is a block of 192K and a block of 316K or more could be arranged.

Bruce