Arnd Bergmann
2026-Jan-05 13:50 UTC
[klibc] [PATCH net-next] net: uapi: Provide an UAPI definition of 'struct sockaddr'
On Mon, Jan 5, 2026, at 09:25, Thomas Wei?schuh wrote:> Various UAPI headers reference 'struct sockaddr'. Currently the > definition of this struct is pulled in from the libc header > sys/socket.h. This is problematic as it introduces a dependency > on a full userspace toolchain. > > Instead expose a custom but compatible definition of 'struct sockaddr' > in the UAPI headers. It is guarded by the libc compatibility > infrastructure to avoid potential conflicts. > > The compatibility symbol won't be supported by glibc right away, > but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either, > so including the libc headers before the UAPI headers is broken anyways. > > Signed-off-by: Thomas Wei?schuh <thomas.weissschuh at linutronix.de>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. The version that worked for my own testing used a nolibc specific definition, which was enough for me to build-test the kernel headers across all architectures, but it does not resolve the dependency. What I'm not sure about is whether the added definition will cause problems for users that include linux/socket.h (or one of the headers using it) before including sys/socket.h. I would expect that this causes build failures on some application source code, but hopefully in a way that is easily fixable by changing the include order. I've added the libc-alpha list to Cc, along with a few developers that care about this. I also found a few older commits in which we've tried to work this out in the past, but each time created a new (or old) problem: 57a87bb0720a ("[PATCH] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h") 304c209c9b02 ("[NET]: Revert socket.h/stat.h ifdef hacks.") 9c501935a3cd ("net: Support inclusion of <linux/socket.h> before <sys/socket.h>") 2618be7dccf8 ("uapi: fix linux/if.h userspace compilation errors") 22bbc1dcd0d6 ("vsock/uapi: fix linux/vm_sockets.h userspace compilation errors") 06e445f740c1 ("mptcp: fix conflict with <netinet/in.h>") c11c5906bc0a ("mptcp: add MPTCP_SUBFLOW_ADDRS getsockopt support") Arnd> --- > include/linux/socket.h | 10 ---------- > include/uapi/linux/if.h | 4 ---- > include/uapi/linux/libc-compat.h | 12 ++++++++++++ > include/uapi/linux/socket.h | 14 ++++++++++++++ > 4 files changed, 26 insertions(+), 14 deletions(-) > > diff --git a/include/linux/socket.h b/include/linux/socket.h > index ec715ad4bf25..8363d4e0a044 100644 > --- a/include/linux/socket.h > +++ b/include/linux/socket.h > @@ -28,16 +28,6 @@ extern void socket_seq_show(struct seq_file *seq); > > typedef __kernel_sa_family_t sa_family_t; > > -/* > - * 1003.1g requires sa_family_t and that sa_data is char. > - */ > - > -/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */ > -struct sockaddr { > - sa_family_t sa_family; /* address family, AF_xxx */ > - char sa_data[14]; /* 14 bytes of protocol address */ > -}; > - > /** > * struct sockaddr_unsized - Unspecified size sockaddr for callbacks > * @sa_family: Address family (AF_UNIX, AF_INET, AF_INET6, etc.) > diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h > index 797ba2c1562a..a4bc54196a07 100644 > --- a/include/uapi/linux/if.h > +++ b/include/uapi/linux/if.h > @@ -25,10 +25,6 @@ > #include <linux/socket.h> /* for "struct sockaddr" et al */ > #include <linux/compiler.h> /* for "__user" et al */ > > -#ifndef __KERNEL__ > -#include <sys/socket.h> /* for struct sockaddr. */ > -#endif > - > #if __UAPI_DEF_IF_IFNAMSIZ > #define IFNAMSIZ 16 > #endif /* __UAPI_DEF_IF_IFNAMSIZ */ > diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h > index 0eca95ccb41e..13a06ce4e825 100644 > --- a/include/uapi/linux/libc-compat.h > +++ b/include/uapi/linux/libc-compat.h > @@ -140,6 +140,13 @@ > > #endif /* _NETINET_IN_H */ > > +/* Definitions for socket.h */ > +#if defined(_SYS_SOCKET_H) > +#define __UAPI_DEF_SOCKADDR 0 > +#else > +#define __UAPI_DEF_SOCKADDR 1 > +#endif > + > /* Definitions for xattr.h */ > #if defined(_SYS_XATTR_H) > #define __UAPI_DEF_XATTR 0 > @@ -221,6 +228,11 @@ > #define __UAPI_DEF_IP6_MTUINFO 1 > #endif > > +/* Definitions for socket.h */ > +#ifndef __UAPI_DEF_SOCKADDR > +#define __UAPI_DEF_SOCKADDR 1 > +#endif > + > /* Definitions for xattr.h */ > #ifndef __UAPI_DEF_XATTR > #define __UAPI_DEF_XATTR 1 > diff --git a/include/uapi/linux/socket.h b/include/uapi/linux/socket.h > index d3fcd3b5ec53..35d7d5f4b1a8 100644 > --- a/include/uapi/linux/socket.h > +++ b/include/uapi/linux/socket.h > @@ -2,6 +2,8 @@ > #ifndef _UAPI_LINUX_SOCKET_H > #define _UAPI_LINUX_SOCKET_H > > +#include <linux/libc-compat.h> /* for compatibility with glibc */ > + > /* > * Desired design of maximum size and alignment (see RFC2553) > */ > @@ -26,6 +28,18 @@ struct __kernel_sockaddr_storage { > }; > }; > > +/* > + * 1003.1g requires sa_family_t and that sa_data is char. > + */ > + > +/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */ > +#if __UAPI_DEF_SOCKADDR > +struct sockaddr { > + __kernel_sa_family_t sa_family; /* address family, AF_xxx */ > + char sa_data[14]; /* 14 bytes of protocol address */ > +}; > +#endif /* __UAPI_DEF_SOCKADDR */ > + > #define SOCK_SNDBUF_LOCK 1 > #define SOCK_RCVBUF_LOCK 2 > > > --- > base-commit: dbf8fe85a16a33d6b6bd01f2bc606fc017771465 > change-id: 20251222-uapi-sockaddr-cf10e7624729 > > Best regards, > -- > Thomas Wei?schuh <thomas.weissschuh at linutronix.de>
H. Peter Anvin
2026-Jan-20 18:50 UTC
[klibc] [PATCH net-next] net: uapi: Provide an UAPI definition of 'struct sockaddr'
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