Re: ABI guarantees

On 8/15/25 02:25, Konstantin Belousov wrote:
> I think that now is the time to discuss the project ABI stability guarantees
> that we provide for the system as the whole.  My personal opinion always is
> that FreeBSD should aim at providing the perfect compatibility.  This can
> be formulated at two levels:
> - from high level view, an app depending on the base library or kernel
>    feature, should never break.
> - a view from the low side would list the technical aspects of things,
>    that allows to provide the guarantee of the high level view.
> 
> We have a lot of facilities to allow the base system evolution while still
> having the stability of interfaces.  I might try to enumerate all that
> features, below is incomplete but representative list of examples:
> - versioning of dsos, both as dso version, and fine-grained symbol versions
> - definition of boundaries, where we provide the binary consumers a view
>    on implementation  (e.g. syscall interfaces, kernel compat syscalls).
> - rtld tricks to provide expected execution environments from older
>    releases on modern systems.
> - kernel support for old binaries formats, older p_osrel, ELF notes to
>    record compilation environment of the binary, etc.

Note that p_osrel is not perfect for dynamic binaries as an old binary on
a newer system might use a newer version of shared library that is compiled
against a newer ABI.

Another gaping hole we have is sysctl().  We have no versioning of the ABI
expected by callers.  Statically assigned MIBs can deal with this by bumping
the constant for the MIB, but most MIBs use OID_AUTO and sysctlbyname()
both of which bypass that.

> So, do we as the project strive to fullfill this goal?  Note that ABI compat
> is not a grading scale: if system fail running some binary, then the compat
> failed.  This is why the feature is hard, in addition to the lot of subtle
> technical details to care about, there needs to be a constistent efforts
> to properly maintain it.

I do disagree slightly about the scale.  In particular, I think for kernel
KPIs used by kernel modules (not userspace), we already have a de-facto
sliding scale.  We do try to keep some kernel modules working across
minor releases (like a NIC driver or perhaps a filesystem), but we do not
constrain the development of things like the VM system such that drm-kmod
is stable.  We also make no promises for any kernel module across major
branches, and in fact encode an explicit MODULE_DEPEND to disallow loading
them.

For userspace I do think we want a higher bar, but I'm not sure that a bar
of "no binary can ever stop working" is fully feasible.  The Secure RPC
case is an example where we've removed the necessary crypto bits because
they are insecure and deprecated.  I would probably rather have stubs
for the libc symbols that fail immediately rather than keeping around the
implementation in the Secure RPC case.  That might depend on your definition
of stability.  Are stub symbols that permit an executable to still load
and execute but encounter errors if using the stubs considered an ABI
compat shim or ABI breakage?  What about cases where we can't support
the old semantics?  In 14.0 (I think) I removed kernel support for several
insecure crpyto algorithms that are formally deprecated for IPsec, and
we no longer support configuring them via setkey(8) or the like.  The
binaries still work, but they will get an error back from the system call
if they use a deprecated algorithm.  Is that ABI breakage?

-- 
John Baldwin