Re: ABI guarantees

On Mon, Aug 18, 2025 at 02:42:49PM -0400, John Baldwin wrote:
> 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.

Neither of tools is perfect.  E.g. symbol versioning only versions symbols,
it does not version types.  So if a type embedded in other types changes,
symbol versioning is not very effective, esp. if type is leaking between
objects.

> 
> > 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.
I talked about ABI. I did not mention API, for which we do not provide
any guarantee, surprisingly for many people. I did not mention
kernel, for which we do not either. In fact, I do not think that we
as the project have resources to do KBI handling. And this is not too
important, IMO, to not have stable KBI even on stable branch.

> 
> 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?
For my definition of stability, yes. This is what I tried to communicate:
if there was some code in the linked image the app expected to see,
then t should be there. Of course there could be nuances like security
consequences or some other pressure, but unless there is a 'fatal'
reason to get rid of the code, facility should be kept.

> 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?

It is fine, it is not ABI, but the environment changing problem.
This is closer to something like a known host that has both ipv4 and v6
addresses, lost its ipv4 part, and gethostname() no longer returning v4.
The analogy is broken, as any analogy, but it is something external to
the app.