From owner-freebsd-hackers Sat Feb 7 13:31:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06337 for hackers-outgoing; Sat, 7 Feb 1998 13:31:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06330 for ; Sat, 7 Feb 1998 13:31:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id NAA05630; Sat, 7 Feb 1998 13:30:16 -0800 (PST) Message-Id: <199802072130.NAA05630@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: ade@demon.net cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: boot floppy banner In-reply-to: Your message of "Sat, 07 Feb 1998 09:04:47 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Feb 1998 13:30:15 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > Makes sense.. though as others have mentioned, perhaps it's time > to move all this stuff to /boot/xxx rather than /boot.xxx, to > prevent clutter in / I'd like this. Bruce; you had some moderately coherent reasons for not liking it last time, do they still hold? > Indeed. Though we still seem to have the bad144 issue floating > around.. until that gets resolved, one way or the other, adding > in this extended boot help functionality is moot, since there's > not enough space in biosboot with BAD144 defined to add anything. BAD144 is a pain. Having said that, I can see where people are coming from with their arguments, and much as it may pain me to say it, they're right. More specifically, removing the BAD144 support from the bootblocks would screw anyone that actually needed it to boot. And the critical issue here is that the FreeBSD bootblock (unlike almost any other bootblock, I might add) actually comprehends the filesystem. The NetBSD, Linux, etc. bootblocks all have the block numbers of the object that they are going to load hardcoded into the bootblock. (Note that here I am talking about the NetBSD second-stage bootblock on i386.) This has a downside; if you boot from a floppy bootblock, it won't be able to read the third-stage item (bootloader, kernel, whatever) from anywhere other than the floppy. > If we're serious about moving towards an ELF based system, then > something is going to *have* to disappear from the current biosboot > code in order to support a.out/ELF kernel loading - which means that > hard decisions are going to have to be made to determine what's going > to get deleted to make space for this extra code. No. What has to happen is that someone has to write the third-stage bootstrap. The biosboot code will shrink substantially when this happens. -- \\ 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