Re: DragonFly boot2 - moved out of commits thread

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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@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.

From booting about a dozen different OS'en in any given year... and 
*chronically* not attached to the same MB, cable/SATA/USB/FW as the last 
time used...

. ..BSD bootblocks+Gag I like.

FICL I can actually understand the inner workings of - but not the *use* 
of.  Too seldom required to use it to remember *how*.

And the so-called 'advanced' OS X 'Openfirmware' or Grub, I would throw 
rocks at were they not so adept at hiding behind an expensive LCD screen....

Keep it simple - let the complexity be chained into..

Bill