From owner-cvs-all Thu Sep 17 09:11:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01935 for cvs-all-outgoing; Thu, 17 Sep 1998 09:11:22 -0700 (PDT) (envelope-from owner-cvs-all) Received: from word.smith.net.au (castles166.castles.com [208.214.165.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA01910 for ; Thu, 17 Sep 1998 09:11:10 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (LOCALHOST [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id JAA00660; Thu, 17 Sep 1998 09:15:37 -0700 (PDT) (envelope-from mike@word.smith.net.au) Message-Id: <199809171615.JAA00660@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Luoqi Chen cc: imp@village.org, peter@netplex.com.au, committers@FreeBSD.org, dillon@backplane.com Subject: Re: buildworld/installworld, minor inconsistancies In-reply-to: Your message of "Thu, 17 Sep 1998 05:02:42 EDT." <199809170902.FAA15168@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Sep 1998 09:15:33 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Warner Losh wrote: > If I understand correctly, the reason for an a.out loader is a normal a.out > executable loads into the below 1M area that DOS uses. Since ELF executables > are loaded well above 1M, there is not need for such a loader, we could just > map in anonymous pages to fill the below 1M area. And the doscmd executable > could even be dynamically linked. The deal is that the doscmd kernel is loaded into the same address space that the DOS environment uses, and so it's linked to run above 1M and has to be loaded specially by the doscmd loader. If the kernel could be configured to load directly above 1M (better above 16M) then that'd be much better, yes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com