On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote: > Jan 30, 2026 17:17:46 Jakub Kicinski <[email protected]>: > > > 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.
