From owner-freebsd-commit Sun Apr 16 05:20:54 1995 Return-Path: commit-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA28589 for commit-outgoing; Sun, 16 Apr 1995 05:20:54 -0700 Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA28576 for cvs-sys-outgoing; Sun, 16 Apr 1995 05:20:51 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA28569 ; Sun, 16 Apr 1995 05:20:44 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id FAA21544; Sun, 16 Apr 1995 05:20:40 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id FAA00243; Sun, 16 Apr 1995 05:20:40 -0700 Message-Id: <199504161220.FAA00243@corbin.Root.COM> To: Bruce Evans <bde@zeta.org.au> cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/i386 locore.s In-reply-to: Your message of "Sun, 16 Apr 95 22:10:52 +1000." <199504161210.WAA05197@godzilla.zeta.org.au> From: David Greenman <davidg@Root.COM> Reply-To: davidg@Root.COM Date: Sun, 16 Apr 1995 05:20:39 -0700 Sender: commit-owner@FreeBSD.org Precedence: bulk >> Modified: sys/i386/i386 locore.s >> Log: >> Remove gratuitous waste of 2K of memory for BIOS variables. We never load >> the kernel at 0-640k; we haven't had the ability to do that since before >> 2.0R. Furthermore, I fail to see how putting an instruction at 0 and then >> doing a .org 0x500 is going to prevent the stuff from getting clobbered >> in the first place; a.out is just too stupid to know about sparse address >> spaces. > >boot.c has `#ifdef REDUNDANT' code to skip over the "BIOS variables" between >(startaddr + 0x400) and (startaddr + 0x4ff) even when startaddr != 0. >Removing the padding is a bit dangerous because bootstraps older than approx. >1995/01/25 don't have `#ifdef REDUNDANT' so they depend on the padding. This would skip over the movw instruction at the beginning (which wouldn't set the warmstart). With the new boot structure, numerous changes to the startup flags, etc, we more or less require people to update the bootblocks anyway. I don't think this is a problem. -DG