From owner-freebsd-hackers Mon Oct 2 11:31:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA13861 for hackers-outgoing; Mon, 2 Oct 1995 11:31:02 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA13856 for ; Mon, 2 Oct 1995 11:30:59 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id EAA23052 for hackers@freebsd.org; Tue, 3 Oct 1995 04:30:54 +1000 From: michael butler Message-Id: <199510021830.EAA23052@asstdc.scgt.oz.au> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: hackers@freebsd.org Date: Tue, 3 Oct 1995 04:30:49 +1000 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1194 Sender: owner-hackers@freebsd.org Precedence: bulk gj%pcs.dec.com@inet-gw-1.pa.dec.com writes: > 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 ? Whilst it's not directly relevant to this discussion .. a trick that Sunsoft (with Interactive Unix) used was to relocate the kernel into physical memory above that magic 16 meg boundary. This means that those machines already crippled with ISA SCSI controllers do slightly less bounce-buffer trickery as the kernel remains memory resident and more of the stuff that's useful to exchange with disk below the 16 meg limit is available. With a 2+ megabyte bloated System V kernel, this is quite beneficial .. How much of this approach could be applied to FreeBSD, I don't know, but it might be worth keeping in mind when redesigning the kernel load sequence, michael