On Sun, 2007-12-16 at 17:44 -0800, Jeff Rizzo wrote:
> 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.

An 'unknown' type current does not have a wedge assigned to it during
boot up.

I've got a need for a Xen instance to have physical access to a wedge
partition directly. It would be nice to label it either with a "XENDISK"
tag, or something else and have NetBSD automatically assign a wedge for
it.

> 
> > 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
>