[PATCH net-next v2 0/4] net: uapi: Provide an UAPI definition of 'struct sockaddr'

[Jakub Kicinski]

On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote:
> Jan 30, 2026 17:17:46 Jakub Kicinski <kuba at kernel.org>:
> 
> > On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote:  
> >> Some of them get broken by the new 'struct sockaddr', but some others are
> >> already broken just by the new transitive inclusion of libc-compat.h.
> >> So any header starting to use the compatibility machinery may trigger breakage
> >> in code including UAPI headers before libc header, even for completely new type
> >> definitions which themselves would not conflict with libc.  
> >
> > Let's split the uAPI header changes from any selftest changes.
> > If you're saying the the selftests no longer build after the uAPI
> > header changes then of course we can't apply the patches.  
> 
> Yes, the selftests don't build anymore after the uAPI changes.
> 
> "can't apply" as in
> * "can't apply separately"
> * "are unacceptable in general"

this one

> * "are too late for this cycle"
> ?
> 
> None of this is urgent.
> We can do the selftests in one cycle and the uAPI in another one.
> Feel free to pick up the patches as you see fit.
> (The mptcp changes already go through their tree, so need to be dropped here)
> I can also resubmit the patches differently if preferred.

The selftests are just a canary in the coalmine. If we break a bunch of
selftests chances are we'll also break compilation of real applications
for people. Subjective, but I don't see a sufficient upside here to do
that.

FWIW the typelimits change broke compilation of ethtool, we'll see if
anyone "outside kernel community itself" complains.