Subject: Re: GPT guids
To: None <firstname.lastname@example.org>
From: Jeff Rizzo <email@example.com>
Date: 12/16/2007 17:44:53
> On Sun, Dec 16, 2007 at 09:28:32AM -0800, Jeff Rizzo wrote:
>> In addition, we need to assign numbers for some other types - RAID, LFS
>> - others folks can think of?
> Well, looking through disklabel.h:
> These could be assigned immediately:
> * 'ffs'
> * 'lfs'
> * 'swap'
> * 'unknown'
I dunno about assigning an 'unknown' specifically for NetBSD.
> These could use more thought.
> * 'boot'
What would a NetBSD "boot" partition be for?
> * 'raid'
> * 'ccd' (it may not be dead yet)
ccd isn't dead yet - and what's to need more thought about for "raid"?
> * 'vinum'? (do any of the BSDs still have vinum?)
FreeBSD already has a GPT type for vinum. :) But since we just removed
it, it seems premature to assign a GPT type for it. :)
>> I think we should do something along the
>> lines of what FreeBSD did - pick a base GUID to indicate "NetBSD", and
>> increment one of the digits for various types therein.
> If that, hopefully the high nibble of the 32-bit segment. :)
> I don't much like searching out a half-byte needle in a 16 byte
> I like what Sun did. They have significant variation
> in the first 32-bit block amongst their partition type GUIDs.
> This also makes things look more uniform, should a
> certain GUID become deprecated.
Yeah, I see what you mean, looking at the list of Sun types. What I
*don't* like is the "separate type for each mounted partition" thing -
seems silly to give /usr a different type than /home.
> (Sun even used a machine in one of their OUI blocks.)
Not sure what you mean by this.
> Do we want to have a number reserved for FFSv2?
> LFSv1? Or use a few of the 16 GUID-specific
> attribute bits to indicate version?
I would tend to think "no" here - the file system code should be able to
distinguish between its own versions - I would think it would be enough
to note "this is NetBSD".
> Also, I believe we need to think more about RAIDframe,
> EFI booting and BIOS booting. (Yes, the latter is possible.)
> Xen domUs present some of the same interestingness.
I agree with this.
Thanks for the feedback.