DragonFly boot2 - moved out of commits thread

[Bill Hacker]

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....
:
:;-)
:
:-Bill

    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.
					-Matt
					Matthew Dillon 
					<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' 
point.

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.