Use a more restricted range of supported FreeBSD_version values
for the virtualbox kernel module since it uses internal KPIs for
which KBI stability is not guaranteed. DECLARE_MODULE_TIED would
tie the module to a specific FreeBSD_version which would cause
the module to stop loading when an SA or EN is pushed on a release
branch. Instead, use DECLARE_MODULE_MAXVER with an upper bound
that is limited to the range of a releng branch so that a module
built on X.Y will load on X.Y with SAs or ENs applied but will
fail to load on X.Y-1 or X.Y+1.
Details
Details
- only compiled, would be good to do runtime testing. This came up at BSDCan as the package built on 11.1 panics when loaded on an 11.2 kernel. This just avoids the panic in that case.
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I will rebase this. @imp and @manu. We might want to do something similar for drm kmods? Not sure if we would want to add KERNEL_RELBRANCHEND upstream in FreeBSD itself at some point? If DRM uses some wrapper around DECLARE_MODULE like DEV_MODULE then it might be simpler to add a dummy module that can use DECLARE_MODULE_WITH_MAXVER directly rather than plumbing through a variant of DEV_MODULE.
Comment Actions
I wasn't aware that this could be possible, I like this a lot. I'll do test and adapt drm-kmod.
Comment Actions
I like the idea.
I also think this should be mentioned in the pkg-message to make sure users are informed.