[no subject]

7d@crater_reader.dragonflybsd.org> <0dd1b0cf082835565b33dce726a5a278.squirrel@www.shiningsilence.com> <D7184C14764249BCB7209145F9A1992E@hermes>
From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: DragonFly boot2 - moved out of commits thread
Date: Wed, 4 Mar 2009 22:06:03 -0800 (PST)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 34
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1236233733 crater_reader.dragonflybsd.org 882 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:13525

    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! 

    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>