ABI guarantees
- Reply: Gleb Popov : "Re: ABI guarantees"
- Reply: John Baldwin : "Re: ABI guarantees"
- Reply: Tomek CEDRO : "Re: ABI guarantees"
- Reply: Jan Bramkamp : "Re: ABI guarantees"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 15 Aug 2025 06:25:28 UTC
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. 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).