The current code in gpt(8) assumes that partitions have a 64
bit attribute field, with all bits created equal, and the
gpt set command simply sets or resets bits in any partition
as requested.
But that's not how the EFI spec defines the field - instead
there are 48 bits which are treated just as described above,
but the other 16 bits have meanings only relative to the partition
type (the owner of the UUID which specifies that type gets to
specify what those 16 bits mean).
I have no idea if anyone has ever really set down a specific
mapping of types and their private 16 attribute bits (several
partition types could share a common definition for those bits
or course).
Do we have any plans to handle that in any way? Currently some
microsoft partition types have defined some bits up there, and
so have FreeBSD (which we seem to have adopted) - and, probably
not by chance, those groups don't overlap. I think there are a
few others as well.
I have a (very hackish) patch to gpt which allows the person running
it to be responsible for setting specific bits which mean something
to the specific partition type ("gpt set bit48" type thing) but I
don't really think that's the right way to approach this (and of course
when displayed, all that ever appears for the bits we don't pretend
we know a name for - regardless of whether that name is appropriate
for the partition type - is a hex bit mask.)
My guess is that the ideal way to handle this would be via an external
mapping table from type-uuids to the names & values of those 16 bits for
that type (with an indirection scheme of some form to allow types to
share the same definitions) - that is, rather than just compiling more
info into the gpt binary (though having the NetBSD partition type attributes
built in would allow use when the external file (or whatever) is unavailable).
kre
