sys: Add DECLARE_MODULE_RELENG for use by external kernel modules

[jhb]

Summary

This macro picks a middle ground between DECLARE_MODULE() (which
defaults to a range of supported kernel versions of the current
version until the end of the stable/X branch) and
DECLARE_MODULE_TIED() (can only be used with the exact kernel version
built against).

When built on a releng/X.Y system, it uses a supported kernel version
range of the current version until the end of the releng/X.Y branch.

When built on a stable/X system, it requires an exact kernel version
similar to DECLARE_MODULE_TIED().

When built on a main system prior to X.0, it uses an effective range
of the current version until the end of releng/X.0. This last case
isn't ideal (would rather have it act like stable/X), but the initial
value of __FreeBSD_version for an X.0 release is not deterministic.

The intended use case for this are modules in ports like virtualbox
and drm-kmod. This will allow a module built on the releng/X.Y branch
to continue to be used after security updates that bump
__FreeBSD_version on the branch, but fail to load on later release
branches on the same stable/X branch.

[jhb]

I would suggest we do something in drm-kmod along the lines of:

#ifndef DECLARE_MODULE_RELENG
#define DECLARE_MODULE_RELENG DECLARE_MODULE
#endif

One could maybe say to use DECLARE_MODULE_TIED as the fallback but that would be kind of ugly for existing releng/X.Y users.

sys/sys/module.h

170

This version is more refined than what I did in virtualbox which always did a roundup() so did not fallback to TIED for stable/X branches.

[imp]

This is a good idea...
Not entirely sure, though, we can hit the KBI stability needed for it.

[jhb]

In D48674#1110075, @imp wrote:

This is a good idea...
Not entirely sure, though, we can hit the KBI stability needed for it.

We generally have managed to have stability on releng/X.Y branches due to the low number of changes, and that's all this requires.

[imp]

Ah releng. I'm extra good

[jhb]

@emaste do you think you can test this with drm-kmod?

[cperciva]

Someone from secteam might correct me, but I don't think we normally bump __FreeBSD_version on releng/X.Y branches after the release. The places I'm aware of where it doesn't end 000 in a release are (a) X.0-RELEASE where we have whatever number HEAD got up to, and (b) rare cases when a new feature is merged after BETA1.

releng-13.1/sys/sys/param.h:#define FreeBSD_version 1301000 /* Master, propagated to newvers */
releng-13.2/sys/sys/param.h:#define FreeBSD_version 1302001 /* Master, propagated to newvers */
releng-13.3/sys/sys/param.h:#define FreeBSD_version 1303001 /* Master, propagated to newvers */
releng-13.4/sys/sys/param.h:#define FreeBSD_version 1304000 /* Master, propagated to newvers */
releng-14.0/sys/sys/param.h:#define FreeBSD_version 1400097
releng-14.1/sys/sys/param.h:#define FreeBSD_version 1401000
releng-14.2/sys/sys/param.h:#define __FreeBSD_version 1402000

I don't object to this change, but I'm not sure that it really wins us much compared to using TIED.

[jhb]

In D48674#1114267, @cperciva wrote:

Someone from secteam might correct me, but I don't think we normally bump __FreeBSD_version on releng/X.Y branches after the release. The places I'm aware of where it doesn't end 000 in a release are (a) X.0-RELEASE where we have whatever number HEAD got up to, and (b) rare cases when a new feature is merged after BETA1.

releng-13.1/sys/sys/param.h:#define FreeBSD_version 1301000 /* Master, propagated to newvers */
releng-13.2/sys/sys/param.h:#define FreeBSD_version 1302001 /* Master, propagated to newvers */
releng-13.3/sys/sys/param.h:#define FreeBSD_version 1303001 /* Master, propagated to newvers */
releng-13.4/sys/sys/param.h:#define FreeBSD_version 1304000 /* Master, propagated to newvers */
releng-14.0/sys/sys/param.h:#define FreeBSD_version 1400097
releng-14.1/sys/sys/param.h:#define FreeBSD_version 1401000
releng-14.2/sys/sys/param.h:#define __FreeBSD_version 1402000

I don't object to this change, but I'm not sure that it really wins us much compared to using TIED.

Hmm, that might be. I think we only don't bump because we fear the binary diffs it would cause. That wasn't the original intention of the version, more an artifact of the limitation of our distribution system.