From owner-freebsd-hackers Tue Feb 21 23:15:19 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA29542 for hackers-outgoing; Tue, 21 Feb 1995 23:15:19 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA29534 for ; Tue, 21 Feb 1995 23:15:10 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA00424; Wed, 22 Feb 1995 18:12:51 +1100 Date: Wed, 22 Feb 1995 18:12:51 +1100 From: Bruce Evans Message-Id: <199502220712.SAA00424@godzilla.zeta.org.au> To: luigi@labinfo.iet.unipi.it, martin@innovus.com Subject: Re: cvs commit: src/sys/i386/boot/dosboot ansi.h boot.c boot.h bootinfo.h cdefs.h dinode.h dir.h dirent.h disk.c disklabe.h dkbad.h Cc: hackers@freefall.cdrom.com Sender: hackers-owner@FreeBSD.org Precedence: bulk >> [merging netboot with fbsdboot] >If someone goes off and does this, keep in mind that the EPROM version >has to stay less than 16K (I think it is over 15K right now). There is >"BOOTROM" define that could be used to keep the memory manager code from >being compiled for EPROM versions. How will the various boots work/be maintained when the standard bootstrap becomes multi-staged? I think I want to have a common big second stage that handles all the interfacing between the BIOS and the kernel. I think the network boot will not need to change much - it can load a second stage over the network. I don't see how the DOS boot could use this scheme. Supporting masses of DOS stuff in the second stage or doing the second stage in the DOS boot is too hard. (Doing a standard first stage is also too hard. I think the DOS boot should only support loading kernels from DOS file systems. Then it wouldn't have to duplicate so many FreeBSD headers.) Bruce