Page MenuHomeFreeBSD

Add apple-zfs and solaris-reserved to make `gpart show` more convenient
ClosedPublic

Authored by otis_sk.freebsd.org on Aug 9 2020, 1:21 PM.

Details

Summary

Introduce G_PART_ALIAS_SOLARIS_RESERVED, GPT_ENT_TYPE_SOLARIS_RESERVED et al., to make gpart show output more convenient on systems with illumos/openindiana disks visible.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

The open question is how to handle GUID 6A898CC3-1DD2-11B2-99A6-080020736631 that is being used for Solaris /usr and also for Apple ZFS. My understanding is that this GUID is a illumos generic one, as in the past, the ZFS codebase was shared between Darwin and illumos, thus, there is this clash.

My personal preference whould be to mark this as Solaris /usr but Apple ZFS seems more consistent with respect to the count of other Apple-related items.

Or if we take into the assumption that there are more illumos/solaris ZFS installations out there than Darwin+ZFS, we also can add other Solaris/illumos GUIDs.

The change seems fine. I don’t feel strongly about the conflicted uuid except it seems to defeat the point of uuids.

Are the two uuids already defined? They must be?

In D26012#577395, @cem wrote:

The change seems fine. I don’t feel strongly about the conflicted uuid except it seems to defeat the point of uuids.

Are the two uuids already defined? They must be?

Yes, they were defined in sys/sys/gpt.h.

The change looks fine to me too.

This revision is now accepted and ready to land.Aug 11 2020, 6:48 PM

While I am at it, I could also introduce the other illumos/Solaris GUIDs, according to available documentation. What do you think?

Should we also mention this in src/lib/geom/part/gpart.8?

One file (sys/disk/gpt.h) was missed out in previous diff.

This revision now requires review to proceed.Aug 11 2020, 7:00 PM

While I am at it, I could also introduce the other illumos/Solaris GUIDs, according to available documentation. What do you think?

Sure, that seems fine to me.

cem added inline comments.
part/g_part.h
50 ↗(On Diff #75694)

Should we comment to the effect that the same uuid is used for some kinds of opensolaris partitions?

This revision is now accepted and ready to land.Aug 11 2020, 7:28 PM
  • More Solaris GUIDs have been introduced
  • Manual page has been updated
  • More manual page (mostly mdoc(7) and mandoc -Tlint related) updates.
This revision now requires review to proceed.Aug 12 2020, 2:01 PM
rpokala added inline comments.
lib/geom/part/gpart.8
755

s/parition/partition/

The gpart changes LGTM, doc changes mostly look good, just a few quibbles below.

lib/geom/part/gpart.8
600–602

What's the motivation for this change? It doesn't seem related and I'm not sure it's correct.

938–959

These UUIDs are uppercase hex, but the rest are lowercase

1502

This is a non-canonical section name/placement. Perhaps this would be a good fit for .Sh CAVEATS, which goes after .Sh AUTHORS?

1505

Why do you need .No here? I think it can be dropped.

lib/geom/part/gpart.8
600–602

This was an output from mandoc -Tlint, .Tn is defunct and should not be used. If these are to be kept, I can keep them.

938–959

Thanks for pointing at this, it was a result of copy&paste.

1502

Moved. I take all advises on this.

1505

Removed.

  • Fixed uppercase leftovers
  • Fixed stray .No.
  • Renamed NOTES to CAVEATS and moved to apropriate place.

Looks fine other than the Tn thing. I think in general we are not adding them and maybe removing them, but it seems orthogonal to the rest of the change.

In D26012#578052, @cem wrote:

Looks fine other than the Tn thing. I think in general we are not adding them and maybe removing them, but it seems orthogonal to the rest of the change.

But I actually did remove them (those .Tn). Should they be added back, you think? What is the rule of thumb? To keep old and/deprecated macros?

In D26012#578052, @cem wrote:

Looks fine other than the Tn thing. I think in general we are not adding them and maybe removing them, but it seems orthogonal to the rest of the change.

But I actually did remove them (those .Tn). Should they be added back, you think? What is the rule of thumb? To keep old and/deprecated macros?

We usually separate the changes to let each one only do exactly one thing. I suggest keeping the new features in this patch and submit another one to apply before or after this one.

  • Re-added .Tn macros around SPARC64 and UltraSPARC to reduce diff
This revision is now accepted and ready to land.Aug 13 2020, 3:07 PM
bcr added a subscriber: bcr.

OK from manpages (with .Dd bump needed).

This revision now requires review to proceed.Aug 13 2020, 3:17 PM

Please accept if this is OK or please request changes. Thanks.

Looks good, thanks Juraj.

This revision is now accepted and ready to land.Aug 17 2020, 5:03 PM