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
<dil...@backplane.com>
