Date: Sat, 6 Jul 2019 00:02:31 +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: <1bd91e31-920c-8857-f900-f66fb99f95d3@selasky.org> In-Reply-To: <97b7657c-53b9-f3d2-f31a-5e56343da71d@FreeBSD.org> References: <201907051226.x65CQUev056366@repo.freebsd.org> <97b7657c-53b9-f3d2-f31a-5e56343da71d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1bd91e31-920c-8857-f900-f66fb99f95d3>