From owner-freebsd-hackers Mon Oct 2 10:49:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12204 for hackers-outgoing; Mon, 2 Oct 1995 10:49:30 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA12199 for ; Mon, 2 Oct 1995 10:49:24 -0700 Received: from rks32.pcs.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA16959; Mon, 2 Oct 1995 10:37:07 -0700 Received: by rks32.pcs.dec.com (Smail3.1.27.1 #16) id m0szohC-0005OqC; Mon, 2 Oct 95 18:30 MEZ Message-Id: To: hackers%freebsd.org@inet-gw-1.pa.dec.com In-Reply-To: Message from Julian Elischer of Mon, 02 Oct 95 04:22:49 MST. Reply-To: gj@pcs.dec.com Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Date: Mon, 02 Oct 95 17:30:29 GMT From: "gj%pcs.dec.com@inet-gw-1.pa.dec.com" Sender: owner-hackers@FreeBSD.org Precedence: bulk Julian Elischer wrote: >> >> >> 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.. > > one answer might be to put the decompression routines and entrypoints > at the END of the file :) > that way you could over-write the beginning as you decompressed (yukko) this idea isn't bad, since the problem seems to be that the decompressing code can be over-written if the kernel is loaded below 3 MB. The 3MB load point was, AFAIK, a seat-of-the-pants decision. At least, it was for me when I was working on the gzip stuff earlier this year and phk seems to have kept it. If we put the code at the end then we might be able to load the compressed kernel at 2 or 2-1/2 MB instead of at 3 MB. By how much is the kernel too big ? I could look into this in my copious spare time :) Gary