Re: Header symbols that shouldn't be visible to ports?

From: David Chisnall <theraven_at_FreeBSD.org>
Date: Thu, 08 Sep 2022 08:24:02 UTC
On 7 Sep 2022, at 15:55, Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> 
> This is exactly what happened with DMD D. When 64-bit statfs was introduced 
> all DMD D compiled programs failed to run and recompiling didn't help. The 
> DMD upstream failed to understand the problem. Eventually the port had to 
> be removed.

I’m not sure that I understand the problem.  This should matter only for libraries that pass a statbuf across their ABI boundary.  Anyone using libc will see the old version of the symbol and just use the old statbuf.  Anyone using the old syscall number and doing system calls directly will see the compat version of the structure.  Anyone taking the statbuf and passing it to a C library compiled with the newer headers will see compat problems (but the same is true for a C library asking a C program to pass it a statbuf and having the two compiled against different kernel versions).

There’s a lot that we could do in system headers to make them more FFI-friendly.  For example:

 - Use `enum`s rather than `#define`s for constants.

 - Add the flags-enum attribute for flags, so that FFI layers that can parse attributes get more semantic information.

 - Add non-null attributes on all arguments and returns that 

 - Use `static inline` functions instead of macros where possible and expose them with a macro for `static inline` so that an FFI layer can compile the headers in a mode that makes these functions that they can link against.  For Rust, this can be compiled to LLVM IR and linked against and inlined into the Rust code, so things like the Capsicum permissions bitmap setting code wouldn’t need duplicating in Rust.

 - Mark functions with availability attributes so that FFI knows when it’s using deprecated / unstable values and can make strong ABI guarantees.

 - Add tests for the headers to the tree.

In 12.0, someone decided to rewrite a load of kernel headers to use macros instead of inline functions, which then broke C++ code in the kernel by changing properly namespaced things into symbols that would replace every identifier.  I’d love to see a concerted effort to use a post-1999 style for our headers.

David