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

On Sun, Dec 16, 2007 at 05:44:53PM -0800, Jeff Rizzo wrote:
> jakllsch@kollasch.net wrote:
> > On Sun, Dec 16, 2007 at 09:28:32AM -0800, Jeff Rizzo wrote:
> >  * 'unknown'
> I dunno about assigning an 'unknown' specifically for NetBSD.

I was thinking for cases where there isn't a GUID assigned
by the proprietor of the file system yet.  For instance UDF
or ISO 9660.  I suppose the Microsoft/Linux general filesystem
GUID could be further abused for this.

> >  * 'boot'
> What would a NetBSD "boot" partition be for?

I'm not sure ... what was it created for originally?

> >  * 'raid'
> >  * 'ccd' (it may not be dead yet)
> >  =20
>=20
> ccd isn't dead yet - and what's to need more thought about for "raid"?

See below.

>=20
> >  * 'vinum'? (do any of the BSDs still have vinum?)
> >  =20
>=20
> FreeBSD already has a GPT type for vinum.  :)  But since we just removed
> it, it seems premature to assign a GPT type for it.  :)

True,
I should have looked at disklabel_gpt.h again before commenting ;)

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

I don't particularly like the different IDs for different mount points
either.

> > (Sun even used a machine in one of their OUI blocks.)
> Not sure what you mean by this.

The last 48-bit block of a [GU]UID is often
a Ethernet MAC address.

Per http://standards.ieee.org/regauth/oui/oui.txt,
08-00-20 is registered to Sun Microsystems.

> > 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.
> >
>=20
> I agree with this.
>=20

Well, mostly do we want GPT partition tables within a RAID-1 area?
Or do we want a raid(4) (RAID-1) device for each separate GPT partition?

Also, do we want the RAIDframe header at the beginning of the
partition still?  (Probably too late to change this.)
You know first hand how GRUB doesn't deal with this well. (Thanks
for the howto BTW.) The EFI/GPT spec explicitly forbids overlapping
partitions (s. 11.2.2.1), which is the abstract solution we've
used to get around this so far.  I suppose we could put the 64
raidframe sectors in their own partition immediately preceding
a RAID-1 area. That or explicitly teach GRUB (v2) about raidframe.
Dunno, just brainstorming here.

Also, cgd(4) may or may not deserve it's own GUID and/or attribute bit.

	Jonathan Kollasch

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

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

iD8DBQFHZpRvOjx1ye3hmokRAp6jAJ95WmAbYC4vuO78fu6kqjkLXMJDNgCfc3kd
7SYz7/gBlvBZJXMomlGNY2Y=
=ZNOn
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--