Re: ABI guarantees

On Mon, Aug 18, 2025 at 3:18 PM Warner Losh <imp@bsdimp.com> wrote:

> > 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.
>>
>
> Yea. We have very weak and limited compatibility on the same branch for
> kernel modules. And we mostly have stuff that's working by accident:
> there's no testing tools to ensure compat. Plus, some things like LinuxKPI
> are overly inlined, encoding far too many offsets in the clients, which is
> a big driver of drmkmod not working from minor release to minor release. It
> would be a heavy lift to fix those design decision: It's possible, but it a
> lot of grunt work.
>

We might have a better chance of catching the breakage within a stable
major branch when ctfdiff(1) is ready. Though the details of what, e.g. the
list of structures and functions, and how that would be enforced still
needs to be nailed-down, at least, some toolings on hand ready-to-use would
be useful in this regard.

Ka Ho


>
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?
>>
>
> Yes. The goals for ABI stability is to run old binaries that used
> supported interfaces on newer versions of FreeBSD. We've never had formal
> support documents. And we certainly have no testing of the assurances that
> we give to our users are working out.
>
> So in general, we should keep things working, keep the old implementation
> around, but no longer exposed. However, for cases like DES where the
> functionality was broken by external forces (eg the crypto algorithms no
> longer hide content), I see that as something out of our control. We don't
> have to support that since they are already de-facto broken and/or are too
> dangerous to use. We have no evidence of use, even, for this use case, so
> there comes a time that we'll have to spend our limited resources on what
> we can support, and do like John suggests and have stubs that insta-fail so
> that old binaries still work to the extent that they don't use the feature.
> Such decisions should be relatively rare, but deliberative and intentional.
> In this case, I'd fall onto the side of support being limited to saying we
> don't support it.
>
> Warner
>