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

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.

On Sat, Jan 31, 2026 at 09:25:17AM -0800, Jakub Kicinski
wrote:
> 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.
Okay. We'll have around this inconsistency then.
> FWIW the typelimits change broke compilation of ethtool, we'll see if
> anyone "outside kernel community itself" complains.
Can you point me to that breakage? I was unable to find it.


Thomas