jakllsch@kollasch.net 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.

+j