svn commit: r349763 - in stable/12/sys: kern sys

[John Baldwin]

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.

-- 
John Baldwin