Wed Mar 4 22:12:28 PST 2009
7d at crater_reader.dragonflybsd.org> <0dd1b0cf082835565b33dce726a5a278.squirrel at www.shiningsilence.com> <D7184C14764249BCB7209145F9A1992E at hermes>
From: Matthew Dillon <dillon at apollo.backplane.com>
Subject: Re: DragonFly boot2 - moved out of commits thread
Date: Wed, 4 Mar 2009 22:06:03 -0800 (PST)
List-Post: <mailto:kernel at crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel at crater.dragonflybsd.org>
Sender: kernel-errors at crater.dragonflybsd.org
Errors-To: kernel-errors at crater.dragonflybsd.org
X-Trace: 1236233733 crater_reader.dragonflybsd.org 882 18.104.22.168
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
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.
<dillon at backplane.com>
More information about the Kernel