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