From owner-freebsd-hackers Thu May 30 05:16:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09132 for hackers-outgoing; Thu, 30 May 1996 05:16:43 -0700 (PDT) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA09115 for ; Thu, 30 May 1996 05:16:40 -0700 (PDT) Received: from localhost.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.6.12/8.6.12) with SMTP id IAA03960; Mon, 27 May 1996 08:54:05 -0400 Message-Id: <199605271254.IAA03960@spooky.rwwa.com> X-Authentication-Warning: spooky.rwwa.com: Host localhost.rwwa.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Michael Smith cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), freebsd-hackers@freebsd.org Subject: Re: three stage boot again In-reply-to: Your message of "Mon, 27 May 1996 15:17:14 +0930." <199605270547.PAA25723@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 May 1996 08:54:04 -0400 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think you're on the money here; the third stage shouldn't care how it > got into memory, it should be able to derive _everything_ by examining the > environment that it finds itself in on startup. Not that I entirely disagree, but just for context, the way DEC does it is with a ``boot parameters block'' which is used to pass parameters from the secondary to the tertiary bootstrap. It includes things like the bootstrap driver, the memory bitmask, boot arguments, boot device, etc... This then becomes a well defined interface between the secondary (machine specific) and the tertiary (machine independent) bootstraps. PS.: The tertiary bootstrap can also load and boot anything, not just VMS... ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM