From owner-freebsd-current@FreeBSD.ORG Sat Apr 26 11:28:29 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39F4C37B401; Sat, 26 Apr 2003 11:28:29 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EEF443FD7; Sat, 26 Apr 2003 11:28:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0174.cvx40-bradley.dialup.earthlink.net ([216.244.42.174] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 199UPO-0007Uh-00; Sat, 26 Apr 2003 11:28:23 -0700 Message-ID: <3EAACF7B.4689948D@mindspring.com> Date: Sat, 26 Apr 2003 11:27:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov References: <20030425202941.GD28920@sunbay.com> <20030426110913.GB9189@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42738e4a3a390e272438f34c008b034b293caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: current@FreeBSD.org cc: John Baldwin Subject: Re: i386/loader compiled with NOFORTH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 18:28:29 -0000 Ruslan Ermilov wrote: > On Fri, Apr 25, 2003 at 04:49:21PM -0400, John Baldwin wrote: > > On 25-Apr-2003 Ruslan Ermilov wrote: > > > But if we manage to load kernel high, above 1M, there > > > should be something that allows us to relocate heap > > > there, no? Also, can't we just trust what BIOS thinks > > > about the amount of memory? > > > > We load the kernel into lower memory first and then copy it > > up above 1mb. The memory above 1mb is not managed by the > > heap and is only used as the destination of the kernel. > > I understand that this is how it works now. The main issue here is the link location for the kernel itself, and the minimum amount of memory FreeBSD wants to require for installation and operation. The problem comes down to not being able to use RAM below the kernel load address until after the kernel is up, after which it can be added to the available kernel memory. The reason for this is that, when you boot, you boot in real mode, and you need to convert from running in real mode to running in protected mode, and you need the image in memory that was loaded by the real mode loader to exactly correspond to the image after relocation, plus some base address, plus some relocation address. What this boils down to is that you want the unrelocated code to look exactly like the relocated code, and then enter protected mode and start executing the relocated code (this is done using a stack trampoline to "return" to the start address of the relocated code in protected mode). FreeBSD fails to implement this wholly in 5 places (one of which is the recursive mapping for the GDT, which is unavoidable), most of which live in assembly language code. > Well, hm, the installation requirement was always slightly > larger than operational, so requiring 8MB for installation > is normal. The "normal" loader can still have its heap > pool in real-mode 1MB, but the "install" loader would > benefit from using say 900K for bzip2 plus the current heap > of 512K, at the top of available memory. Just like we > "load" kernel and other modules there, we could modify heap > routines to operate in upper memory, no? Is this handled > by the i386_copy{in,out} stuff in sys/boot/i386/libi386? If you want more low memory available, you have to sacrifice high memory, which means sacrificing size for minimal install and run. This doesn't mean 8M, this more likely means 12M, or more: N = low_mem_for_loader + minimum_required_kernel_mem The only real alternative to this is not an alternative: make all the code in the kernel PIC, so that it can be relocated anywhere, and isn't linked against a specific base address. It's not an alternative because the toolchain (apparently) still has problems statically linking PIC objects. > > I guess the real reason for your questions is that bzip2 > > requires some outrageous amount of memory for some internal > > tables? Does bzip2 really buy us that much more space than > > gzip in this case? > > Here are the 5.0-R numbers, from kern.flp and mfsroot.flp: > > -r-xr-xr-x 1 root wheel 1310896 Jan 17 00:45 kernel.gz > -r-xr-xr-x 1 root wheel 1247884 Apr 26 14:00 kernel.bz2 > -rw-r--r-- 1 root wheel 1407218 Jan 17 00:39 mfsroot.gz > -rw-r--r-- 1 root wheel 1358835 Apr 26 14:01 mfsroot.bz2 > > That is, saves us 50-60K of space on 1.44MB floppies. I'm guessing that it doesn't really, and what you are pointing to here is bzip2 results that are based on more than -1 (i.e. you are assuming that the memory limits aren't being enforced on bzip2 by the loader), right? What are the numbers when -1 is used instead? -- Terry