On 2019-07-08 19:09, John Baldwin wrote:
On 7/5/19 3:02 PM, Hans Petter Selasky wrote:
On 2019-07-05 17:49, John Baldwin wrote:
How does this not break the module KBI? You've removed epoch_*_KBI symbols used
by existing modules, and you appear to have changed the size of the
'struct epoch_tracker' object that existing modules allocate on the stack and
pass to functions in the kernel. Bumping __FreeBSD_version is not sufficient
cover to break the KBI of widely used interfaces in stable (while we don't
enforce KBI for all parts of the kernel, locking primitives is one of the things
we can't break).
Hi John,
I'm aware there is a KPI breakage, but there is no API or functionality
breakage.
The epoch(9) API is a very new API and I don't expect it to be widely
used for binary only modules. Do you have any examples otherwise?
man 9 epoch
clearly states:
NOTES
The epoch kernel programming interface is under development and is
subject to change.
epoch(9) is currently mostly used inside the kernel which has to be
re-compiled.
If you think it is really important that epoch(9) will stay KBI
compliant I'll do the work to fix that.
Despite the NOTES claim, given its wide use it is effectively part of the KBI
just as much as 'struct mtx'. We also do not limit KBI to just binary-only
modules. It makes it much harder to test for one thing. You should be able
to take a 12.0 if_tap.ko and load it and use it with a stable/12 GENERIC
kernel for example. I think you've broken that.
Maybe I'm missing something, but won't this be blocked by the
incremented __FreeBSD_version value in 12-stable vs 12.0 ???
--HPS
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"
