Subject: Re: GPT guids
To: None <>
From: Jeff Rizzo <>
List: tech-userlevel
Date: 12/16/2007 17:44:53 wrote:
> 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
> haystack.
> 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.

>> Thoughts?
> 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.