From owner-freebsd-hackers Sat Feb 7 07:05:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15947 for hackers-outgoing; Sat, 7 Feb 1998 07:05:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sphinx.lovett.com (root@sphinx.lovett.com [38.155.241.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA15942 for ; Sat, 7 Feb 1998 07:05:16 -0800 (PST) (envelope-from ade@demon.net) Received: from gorgon.lovett.com [38.155.241.3] (ade) by sphinx.lovett.com with esmtp (Exim 1.82 #1) id 0y1BoF-00013u-00; Sat, 7 Feb 1998 09:04:47 -0600 To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: boot floppy banner Organization: Demon Internet Reply-To: ade@demon.net In-reply-to: Your message of "Thu, 05 Feb 1998 22:14:09 +1030." <199802051144.WAA00426@word.smith.net.au> Date: Sat, 07 Feb 1998 09:04:47 -0600 From: Ade Lovett Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" Mike Smith writes: > >It occurred to me this morning that the *ideal* behaviour would be as >follows: > >If boot.banner exists, display it, else if boot.help exists, display it. >Don't have a 'help' command. Instead, if an unrecognised command is >entered, and finding a kernel named thus fails, look for a file named >boot. and display it instead. 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 / >This lets you have more than one help screen, just for openers. It >might even reduce the code footprint a little. 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. I'm also starting to tinker with FreeBSD/ELF -- I've read John's comments about the bootloader that supports both a.out and ELF kernels being too big (presumably because it has the BAD144 cruft in it as well). 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. BAD144 support in biosboot certainly seems to be a prime contender for deletion to support any extra functionality. -aDe -- Ade Lovett, Demon Internet, Austin, Texas.