DragonFly boot2 - moved out of commits thread
wbh at conducive.org
Mon Mar 2 12:14:32 PST 2009
Matthew Dillon wrote:
:If legacy boot2 couldn't grow beyond 8K, (or 16K) neither a 32K nor 64K
:wrap would have mattered?
:And one can put a reasonably useful 16-bit Virtual Machine OS, Virtual
:Memory System, with disk I/O and an editor into 8K. Even on an 8-bit
:CPU. Forth and ASM didn't go away. They just hide really well....
The 32 bit disklabel only has 8K of space reserved to hold boot2.
The 64 bit disklabel has 32K of space reserved to hold boot2.
The boot1 code prior to this fix could only load up to an 8K boot2
due to segment wrapping.
The boot1 code after this fix can now load up to a 16K boot2 before
it hits the segment wrapping problem.
Adjusting boot1 to be able to load an even larger boot2 would
require a lot more messing around then I want to do.
<dillon at backplane.com>
I'd like to suggest it not even be contemplated. No need.
- The 'classical' *BSD initial boot selector lacks very little in the
way it *acts*... and needs not the Lilo/Grub editing for device
positional changes, removables insertion et al - given that /etc/fstab
can also be made adaptable to label/named devices vs channel,
device-type and attach-point-sequence *generated* ID's.
- 16K is enough space to hold a 'next-stage' bootloader with menus, and
a bit of graphics (Gag is a good look-and-feel example, BSD splash
screens less so..).
AND a choice to go back and try another device... before mounting fs'en.
Basically not a 'program' in the Von Neumann sense at all - rather a
simpler 'state machine'.
All presuming that 'chainloading' - of as many stages as are needed -
handles the rest from nothing more demanding than a predictable 'miet'
IMNSHO, better to have extra players in the sequence, many extra, if
need be - than to make the first two stages not only 'fat'...
. .. but overly specialized.
More information about the Kernel