send/recv: open up additional stream feature flags

[robn]

Motivation and Context

We have only one DMU feature flag bit left. In #14997 I proposed using it to signal the presence of a features nvlist in the BEGIN record where more features may be listed, following the pattern used by pool features. @pcd1193182 suggested that maybe we could just sidestep the problem by taking the extra "reserved" bits in drr_versioninfo. This PR does just that.

Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.

Description

The docs for drr_versioninfo have marked the top 32 bits as "reserved" since its introduction (illumos/illumos-gate@9e69d7d). There's no indication of why they're reserved, so it seems uncontroversial to make a lot more flags available.

I'm keeping the top eight reserved, and explicitly calling them out as such, so we can extend the header further in the future if we run out of flags or want to do some kind of change that isn't about feature flags.

This is actually only a documentation update. The "reserved" bits were never actually expressed in code anywhere.

I've also moved some comments around a little to put them near the thing they're describing. This file seems a little confused, but now maybe slightly less so.

Discussion

I still think #14997 or something like it is the better solution. Its true that there is not a huge demand for stream features, so making more flags available means we're unlikely to need to consider it for a good long while, but also supply can increase demand, especially if we start taking on more "new algorithm" features (#15215 was my original reason for looking at this). It also still suffers from the problem of private use of conflicting flags: bits 3-15, 18 and 28 are apparently unusable but there's no record of what they are or whether they're still needed (that I could discover, at least).

If nothing else, the commentary is wrong: bit #29 is not actually the last available bit by the old scheme, but actually bit #31. I assume this was a misreading of the BF64_GET/BF64_SET macros: the second arg is number of bits, not top bit.

How Has This Been Tested?

Compile checked only.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[robn]

@behlendorf bump!

[amotin]

Solution to both problems of number of bits and possible conflicts would be using features representation similar to pool features, including textual names and may be compatibility restrictions. But I don't insist on it now. For now just one comment below.

[robn]

Solution to both problems of number of bits and possible conflicts would be using features representation similar to pool features, including textual names and may be compatibility restrictions.

That's sort of what #14997 is looking towards, though I haven't thought about it for a long while.