Date: Mon, 18 Aug 2025 23:54:20 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org Subject: Re: ABI guarantees Message-ID: <20250818235420.0d245ef1@nuclight.lan> In-Reply-To: <2fce0bfb-9ce7-40ce-8a27-f0103f531ca0@FreeBSD.org> References: <aJ7S2OeO7Sj2bw8b@kib.kiev.ua> <2fce0bfb-9ce7-40ce-8a27-f0103f531ca0@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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, @nuclighthelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250818235420.0d245ef1>