Thread (20 messages) 20 messages, 3 authors, 2d ago

Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack

From: Fernando Fernandez Mancera <hidden>
Date: 2026-07-13 14:57:25
Also in: batman, bridge, intel-wired-lan, linux-fsdevel, linux-nfs, linux-rdma, linux-s390, linux-scsi, linux-sctp, linux-wireless, lkml, lvs-devel, mptcp, netfilter-devel, target-devel

On 7/13/26 4:22 PM, Arnd Bergmann wrote:
On Mon, Jul 13, 2026, at 16:00, Fernando Fernandez Mancera wrote:
quoted
On 7/12/26 1:01 PM, Arnd Bergmann wrote:
quoted
On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
quoted
Historically, the IPv4 protocol has been linked to the core INET
subsystem. Because shared infrastructure like the TCP/UDP engine,
routing or INET hashtables live inside net/ipv4/, it has been impossible
to compile a kernel with only IPv6 support.

This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
'def_bool y' for now. This does not allow to completely disable the
IPv4 stack yet but it lays the necessary build-system work for that
goal.
I expect this will cause additional (trivial) build regression in the
next step when randconfig builds run into obscure corner cases, either
with INET=y IPV4=n IPV6=y or with INET=y IPV4=n IPV6=n.

I can probably give your patch (with IPV4 visible or disabled) an
early go on the randconfig tree to find these more quickly.
If I run into regressions, should I just add more 'depends on IPV4',
or do you have other plans?
Yes, I have a job running randconfig and verifying nothing breaks. If
something breaks and it isn't core networking stack I would just make
the Kconfig symbol depend on IPv4.

Then later we will have more time to write a dedicate patch so it does
not depend on IPv4.
Ok
quoted
quoted
Should we have some logic to ensure that at least one of IPV4 or
IPV6 is enabled? I think this would work

config IPV4
        bool "The IPv4 protocol" if IPV6
        default INET

which only allows turning IPV4 off if IPV6 has enabled.
I do wonder, should we? I mean, I didn't try it off but I don't see why
we should not allow a pure L2 system..
I expected a pure L2 system to be CONFIG_ETHERNET=y CONFIG_INET=n.

Which user-visible parts of CONFIG_INET would you want keep working
when both v4 and v6 are disabled?
Yes, you are right. So I think introducing something as you proposed 
makes sense. Right now I cannot think about something needed from INET 
for pure L2.

Thank you!
Fernando.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help