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

[Hans Petter Selasky]

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