On 2026-01-05 05:50, Arnd Bergmann wrote:

This looks like the right approach to me. I have previously
tried to introduce a 'struct __kernel_sockaddr' structure and
use that in uapi headers in place of the libc sockaddr, but
that seemed worse in the end, and introduce the same problems
as using the existing __kernel_sockaddr_storage.

You say "the same problems". It's not clear to me what that means.

Based on my own libc experience, hacking both a minimal (klibc) and a
maximal (glibc) libc, there are a *lot* of advantages to having
__kernel_* definitions available, *regardless* of if they are exported
into the libc namespace at all.

Specifically:

1. When calling explicit kernel interfaces, like ioctl(), it is the
   kernel interfaces, not the libc interfaces, that needs to be
   used. However, the rest of the application may need to include the
   libc headers.

2. The libc *implementation* may need to have both the kernel and the
   libc interfaces available.

In the case of struct sockaddr et al, it probably matters less,
because it isn't practical for them to be different for other
reasons, but it has been a real problem for things like termios.

On the flipside, for things where the kernel interfaces are inherently
necessary, we really want the libc authors to be able to use the uapi
headers. However, they have to be concerned about things like
namespace restrictions.

So I have a very, very strong vote for using and even expanding the
use of __kernel_* in the uapi headers. In fact, it would even be nice
to have a variant of "make headers_install" that automatically
transmogrifies symbols; if it isn't doable with simple pattern
matching then perhaps using coccinelle.

Allowing the libc authors to modify those transmogrification rules
would definitely be better than having various kinds of header guards.

	-hpa