From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Alyssa Ross <hi@alyssa.is>,
netfilter-devel@vger.kernel.org,
Joshua Lant <joshualant@googlemail.com>
Subject: Re: [PATCH nftables] include: fix for musl with iptables v1.8.11
Date: Wed, 11 Feb 2026 19:59:33 +0100 [thread overview]
Message-ID: <aYzRlXaSetejciwU@orbyte.nwl.cc> (raw)
In-Reply-To: <aYyI9kN4FAgbFUA-@strlen.de>
On Wed, Feb 11, 2026 at 02:49:42PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > On Thu, Jan 09, 2025 at 01:03:25AM +0100, Pablo Neira Ayuso wrote:
> > > Hm. I am looking at include/uapi/linux/netfilter_bridge.h and...
> > >
> > > #include <linux/in.h>
> > > #include <linux/netfilter.h>
> > > #include <linux/if_ether.h>
> > > #include <linux/if_vlan.h>
> > > #include <linux/if_pppox.h>
> > >
> > > I don't understand why all those #include need to be there, this
> > > header file contains only defines an enumeration... git annotate takes
> > > me to:
> > >
> > > 607ca46e97a1 ("UAPI: (Scripted) Disintegrate include/linux")
> > >
> > > Silly question: Does it break any netfilter userspace software if
> > > #include <linux/if_ether.h> is moved from that kernel header file to
> > > to the non-uapi netfilter_bridge.h header file.
> >
> > Silly counter question: Does removing an include statement break UAPI?
>
> Yes, it risks uapi breakage.
I hope this extra include is safe in that regard.
> > BTW: I see only a single UAPI kernel header include from netinet space
> > (include/uapi/linux/mptcp.h) and it's for compat reasons (06e445f740c1
> > ("mptcp: fix conflict with <netinet/in.h>")). Speaking of which, what if
> > we added:
> >
> > | #ifndef __KERNEL__
> > | #include <netinet/if_ether.h>
> > | #endif
> >
> > early into include/uapi/linux/if_ether.h? Aside from any header caches,
> > this should fix all of user space at once, no?
>
> Phil, would you send a formal patch to make this workaround *ONLY* in
> netfilter_bridge.h (06e445f740c1)?
DONE.
> That way the fix can be propagated to nftables.git without having to
> adjust cached headers on every update.
I assume you prefer to keep headers untouched which are
iptables-specific. But why not attempt to patch if_ether.h itself?
Cheers, Phil
next prev parent reply other threads:[~2026-02-11 18:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 23:10 [PATCH nftables] include: fix for musl with iptables v1.8.11 Alyssa Ross
2024-12-20 11:50 ` Phil Sutter
2024-12-20 12:07 ` Alyssa Ross
2024-12-20 12:33 ` Phil Sutter
2024-12-21 15:34 ` Alyssa Ross
2025-01-08 23:34 ` Pablo Neira Ayuso
2025-01-08 23:49 ` Phil Sutter
2025-01-09 0:03 ` Pablo Neira Ayuso
2025-01-09 10:02 ` Phil Sutter
2026-02-11 13:49 ` Florian Westphal
2026-02-11 18:59 ` Phil Sutter [this message]
2026-02-11 19:09 ` Florian Westphal
2026-02-11 20:19 ` Phil Sutter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYzRlXaSetejciwU@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=fw@strlen.de \
--cc=hi@alyssa.is \
--cc=joshualant@googlemail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.