Re: DragonFly boot2 - moved out of commits thread

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

7d@crater_reader.dragonflybsd.org> <0dd1b0cf082835565b33dce726a5a278.squirrel@www.shiningsilence.com> <D7184C14764249BCB7209145F9A1992E@hermes> <200903050606.n256634C061785@apollo.backplane.com>
In-Reply-To: <200903050606.n256634C061785@apollo.backplane.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 92
Message-ID: <49af7acd$0$879$415eb37d@crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 61.10.57.144
X-Trace: 1236237005 crater_reader.dragonflybsd.org 879 61.10.57.144
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:13526

Matthew Dillon wrote:
>     At the moment our boot loader is just the FreeBSD boot loader,
>     though I have made significant modifications to boot1 / boot2
>     to better abstract out all the absolute addresses the originals used.
> 
>     I never liked the FICL stuff.  It is almost unreadable to me which
>     makes modifying it difficult.  All of that just for a simple menu
>     system! omg! 
ROFL!

A Forth coder would say the same - only in stronger language - about 
anything that starts with 'include ...' - or uses massive libs.

;-)

But the reason for using Forth for a loader is not merely historical.

Forth is generally unsuitable for 'general purpose' use nowadays - if 
only because it can give entirely 'too much' control - down to the 
hardware layer - in what we dare permit for a secured multi-user 
environment, and it is bleeding hard to box that, even with 'fence'ing.

HOWEVER - it remains highly portable, and - most of all - regardless of 
any execution-speed penalty, very, very hard to surpass for small 
footprint AND portability combined.

And - for where we use it - very little change has been needed over a 
longish time span, so the benefits still outweight the 'costs' - at 
least IMNSHO. I gave up machine-coding AND asm for Forth as SO much 
easier it was astounding, given that I had 8080, Z80, 6809, 68000, 8086, 
80286, 80386 all in my environment at much the same time.

> 
>     I certainly don't mind if someone wants to mess with /boot/loader.
> 
>     My only personal interest is in making boot2 work for disklabel64.
>     The boot2 space in traditional disklabels is only 8K.  We have 32K of
>     space in disklabel64's but the segmentation model that boot1 runs
>     under has a 16K limitation for loading boot2 due to the BTX origin
>     of $0xC000 (it was $0xE000 prior to my last set of commits).
> 
>     16K is enough for considerable sophistication, however.  I can easily
>     fit HAMMER, UFS1, and UFS2 support into a 16K boot2.  That is what I
>     just finished doing.  There are a few more things I am going to do
>     related to properly detecting maxed out DOS slice tables on drives
>     > 2TB (where the ending LBA is maxed out), in order to allow a properly
>     sized disklabel64 (> 2TB) to be specified within such slices.
> 
>     Our kernel has GPT support too, now, but nobody is seriously using GPT
>     yet and our only GPT editor is the original one from FreeBSD (that
>     FreeBSD has now abandoned).  Still, it is something to think about.
>     Personally speaking I far prefer the disklabel64 structure I created
>     last year.  It uses 64 bit byte offsets instead of sector numbers
>     (making disk images far more portable), full support for uuid's,
>     and it implements out-of-band partitions just like GPT does.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>

I'll take that a step further;

Just as the boot loader was imported FROM FreeBSD, I'd like to be able 
to JF drop-in your modern toolset into OpenBSD, and NetBSD as well as 
FreeBSD.

In the days of small HDD, Net and Open's arcane and antiquated disk 
handling tools were a mere annoyance. Multiple spindles and smaller 
salvaged HDD are only a partial solution.

When one wants to make better use of ever-cheaper large media - 500 GB 
to 1.5 TB now common, the limited ability to slice, partition and mount 
'more subunits' AND/OR 'the other guy's' storage, are a barrier to 
pan-BSD testing and development work.

DragonFlyBSD presently has the most pragmatically useful approach to 
that, and it looks to scale to even larger storage.

It is also important (to me) to be able to handle both/either GPT and 
'legacy' - more than one kind of 'legacy' at that. Minix, Syllable, et al.

The 'holy grail' would also include abilty to work with Apple-formated 
media, as they march to the beat of yet-another drum, even when using 
so-called 'Apple-UFS' and DO now have a significant 'ABM' market share - 
allegedly more than Linux.

I don't really see much need to cater to Windows. Separate worlds, and 
dead-easy to fire up a Qemu instance from whatever NT4 or later license 
one has available, as Windows should never be allowed direct networking 
in any case.

Bill