# Re: \[klibc\] \[PATCH net-next\] net: uapi: Provide an UAPI definition of 'struct sockaddr'

- From: Arnd Bergmann \<arnd@arndb.de\>
- Date: 2026-01-20 22:32:43 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2026/01/3378844
- Thread: https://ratatoskr.run/netdev/2026/01/3352392/t.md

```text
On Tue, Jan 20, 2026, at 19:50, H. Peter Anvin wrote:
> 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.

I must have accidentally cut that from my reply, sorry.
Looking at it again now, I think I ran into problems with the
flexible array that was removed from the in-kernel sockaddr
structure in commit 2b5e9f9b7e41 ("net: Convert struct sockaddr
to fixed-size "sa_data[14]""), so there is a good chance it works
now with the (once more) fixed-size version.

The other problem is that the structures that embed 'sockaddr'
are used a lot inside of the kernel, in particular in 'ifreq',
so changing the uapi sockaddr to __kernel_sockaddr requires
additional changes wherever the struct members are passed
by reference.

> 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.

Absolutely, I am totally in agreement about this in general, which
is why I tried this approach first.

      Arnd
```