DragonFly kernel List (threaded) for 2009-03
DragonFly BSD
DragonFly kernel List (threaded) for 2009-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly boot2 - moved out of commits thread

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Tue, 03 Mar 2009 04:14:32 +0800

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.

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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]