--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 16, 2007 at 09:28:32AM -0800, Jeff Rizzo wrote:
> Now that I'm doing my semiannual playing around with wedges and gpt and
> all that, I'm thinking about the fact that NetBSD doesn't yet have any
> GUIDs assigned specifically for our use - we're using FreeBSD's UFS ID
> by default.

Look at Linux and Microsoft :P

>=20
> Now, I'm not nearly as knowledgeable about this as some folks that I
> hope will pipe up in this discussion, but re-using FreeBSD's ID seems
> like we're just asking to duplicate the whole "MBR partition type 165 vs
> 169" situation.  Unless I'm very much mistaken, our UFS isn't exactly
> like FreeBSD's - plus, there's times when you want to be able to tell
> for certain what OS is on a disk without having to look at its contents.
>=20
> 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'

These could use more thought.
 * 'boot'
 * 'raid'
 * 'ccd' (it may not be dead yet)
 * 'vinum'? (do any of the BSDs still have vinum?)

That's probably most of them that I consider to be enough ours
that we could assign numbers.

> 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.
(Sun even used a machine in one of their OUI blocks.)

> 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?=20

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.

	Jonathan Kollasch

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHZc72Ojx1ye3hmokRAip3AJ9uNFqdKRyBtbVC9SBqYk2DHdQmmQCeMIzm
5qgQ9WKO51quumv5ScofOqU=
=mBP4
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--