On 7/12/26 1:01 PM, Arnd Bergmann wrote:
On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
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.
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..
Thanks,
Fernando.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
