Re: ABI guarantees

On 15.08.25 08: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.
> But the complete list of low level features to handle ABI stability while
> evolving, is not the point.  The users really only care about the high
> level view, they need ability to run the old binaries on their modern
> systems.
>
> 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.

Aiming for perfection will slow progress to a crawl and calcify the system.

I would argue that there is a grading scale. It matters what stops 
working and how.

* Does an application no longer link?

* Does it stop being usable (at runtime)?

* Did we just restrict the feature set offered by the base system e.g. 
remove one of may ciphers?

Also what type of command was it?

* Did we break basic userland command like ls, netstat, ifconfig?

* Did the way PF loads rules at the syscall level change, but the libpf 
ABI was kept stable? What's the stable ABI boundary?

* Did we "just" change a RAID card or NIC driver and now the old low 
level driver specific tool doesn't work anymore (e.g. driver and 
firmware update utility have be in sync)?


> I am asking about the project goal because the common theme of several
> recent commits or, put it differently, breakage from them, were ABI
> breakage.  If we care, then we need to care more.  If not, then the
> policy should be clearly formulated and the burden ease on the developers.
>
> I do hope that we would continue care about ABI. Of course with our resources
> we cannot be perfect at level of Windows, but we can do much better than
> we do now.
>
> The stability (as in ABI stability) was one of the features of FreeBSD
> that was the reason to use and care about it as the main personal
> computing platform. I expect that a lot of users also depend on this
> aspect, judging by the reaction to the broken stuff (and some non-public
> feedback on things like iBCS2 compat removal etc).

I would argue that if you bypass libc and libsys while writing you're 
own language runtime you don't get to complain about non-malicious breakage.

What makes the current breakage in -CURRENT so damn annoying for 
developers dog-fooding FreeBSD is how slow the ports build cluster is to 
catch up after necessarily breaking changes like switching the default 
Kerberos implementation or importing a new OpenSSL version. The official 
packages repositories have been severely broken for about a month now.

I want the official build infrastructure to build AMD64 and ARM64 
-CURRENT more frequently and release repositories for both base and 
ports in sync.

I don't want to to run my own beefy build infrastructure just to 
regression tests on -CURRENT.

By making it such a pain in the ass to run -CURRENT we all but guarantee 
a bad .0 release with lots of easy to find and fix bugs.