Re: Metalanguage for the Linux UAPI

[Willy Tarreau <w@1wt.eu>]

On Thu, May 15, 2025 at 02:24:29PM -0700, H. Peter Anvin wrote:
> On 5/15/25 13:26, enh wrote:
> > On Thu, May 15, 2025 at 4:05 PM H. Peter Anvin <hpa@zytor.com> wrote:
> > > 
> > > OK, so this is something I have been thinking about for quite a while.
> > > It would be a quite large project, so I would like to hear people's
> > > opinions on it before even starting.
> > > 
> > > We have finally succeeded in divorcing the Linux UAPI from the general
> > > kernel headers, but even so, there are a lot of things in the UAPI that
> > > means it is not possible for an arbitrary libc to use it directly; for
> > > example "struct termios" is not the glibc "struct termios", but
> > > redefining it breaks the ioctl numbering unless the ioctl headers are
> > > changed as well, and so on. However, other libcs want to use the struct
> > > termios as defined in the kernel, or, more likely, struct termios2.
> > 
> > bionic is a ("the only"?) libc that tries to not duplicate _anything_
> > and always defer to the uapi headers. we have quite an extensive list
> > of hacks we need to apply to rewrite the uapi headers into something
> > directly usable (and a lot of awful python to apply those hacks):
> > 
> > https://cs.android.com/android/platform/superproject/main/+/main:bionic/libc/kernel/tools/defaults.py
> > 
> 
> Not "the only".

Indeed, nolibc (/tools/include/nolibc) directly includes uapi as well, and
since nolibc doesn't compile anything but only exposes include files, these
appear as-is in the application. So far the headers look clean enough for
our use cases and have not caused problems. But admittedly, applications
are small and limited (selftests and init code).

One thing we've been considering which we would find convenient there
would be to generate an indirection layer for all files that would include
the right one depending on the detected arch so as to ease compilation for
any arch with all the uapi files available, as it seems totally feasible
right now (i.e. each .h file would just have "#if defined(__arch_xxx__)
#include <arch_xxx/foo.h>" etc). We could imagine having a
"make install-all-headers" target to produce that thing for example. I'm
sharing this so that you can also have this in mind to consider whether or
not your chosen approach would break that possibility.

Just my two cents,
Willy