Date: Mon, 8 Jul 2019 21:26:58 +0200 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-12@freebsd.org Subject: Re: svn commit: r349763 - in stable/12/sys: kern sys Message-ID: <bf7d194e-e11a-b8ac-25d2-e1f2c6306f26@selasky.org> In-Reply-To: <3f85335c-635e-c37f-f887-39c1c3e7858d@FreeBSD.org> References: <201907051226.x65CQUev056366@repo.freebsd.org> <97b7657c-53b9-f3d2-f31a-5e56343da71d@FreeBSD.org> <1bd91e31-920c-8857-f900-f66fb99f95d3@selasky.org> <3f85335c-635e-c37f-f887-39c1c3e7858d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bf7d194e-e11a-b8ac-25d2-e1f2c6306f26>