Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Feb 1998 13:30:15 -0800
From:      Mike Smith <mike@smith.net.au>
To:        ade@demon.net
Cc:        Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG
Subject:   Re: boot floppy banner 
Message-ID:  <199802072130.NAA05630@dingo.cdrom.com>
In-Reply-To: Your message of "Sat, 07 Feb 1998 09:04:47 CST." <E0y1BoF-00013u-00@sphinx.lovett.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802072130.NAA05630>