Re: ABI guarantees

On Mon, 18 Aug 2025 14:42:49 -0400
John Baldwin <jhb@FreeBSD.org> wrote:

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

Would changing binary structures to some standard format e.g. CBOR (think it
like binary JSON) or even ng_parse() ASCII format (or teach ng_parse() doing
CBOR) help to alleviate the problem? ng_parse() allows to define many C
structures by mechanical sed to macros.

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

Don't know about IPsec but deleting blowfish was surely a mistake - it is
not broken and could be used e.g. in IoT where space constraints matter, for
those who know what they are doing.

-- 
WBR, @nuclight