On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote:
Jan 30, 2026 17:17:46 Jakub Kicinski [off-list ref]:
quoted
On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote:
quoted
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.