linux-kernel - Re: Metalanguage for the Linux UAPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi7sLm+zHUkyFO8V6QNghLQn0yiWsHfm8WU=V15K7K07Q@mail.gmail.com>
Date: Thu, 15 May 2025 14:20:28 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Arnd Bergmann <arnd@...db.de>, LKML <linux-kernel@...r.kernel.org>, 
	libc-alpha@...rceware.org, linux-arch@...r.kernel.org
Subject: Re: Metalanguage for the Linux UAPI

On Thu, 15 May 2025 at 13:05, H. Peter Anvin <hpa@...or.com> wrote:
>
> 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.

Honestly, I *really* don't want to go down that rat-hole.

It's going to be full of random project-specific issues, and the
bigger projects - like glibc - wouldn't use the kernel headers anyway,
even with some generic language, because they have their own history,
they deal with lots of other non-Linux platforms, and it's just all
downside for them.

In fact, it's all downside for the kernel too. I do *not* want kernel
headers to be used by other projects, because I simply don't want to
hear about "we do Xyz, so the innocuous uapi header change breaks
Abc". It's all pain, for no gain.

So as far as I'm concerned, the uapi header split has been very
successful - but not because other projects can then use our uapi
headers. No, purely because it helped *kernel* people be more careful
about a certain class of changes, and was a big read flag in that it
made people go "Oh, I can't just change that structure, because it's
exported as an API to user space".

If you _really_ want to do a Metalanguage for these things, and want
to support lots of different namespace issues, several different
languages etc, I have a very practical suggestion: make that
metalanguage have a very strict and traditional syntax. Make it look
like C with the C pre-processor.

There are lots of libraries and tools to parse C, and turn it into
other forms. Making up a new language when we already *have* a good
language is all kinds of silly. Just use the language it already is
in, and take advantage of the fact that there's lots of infrastructure
for that language.

                    Linus