Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack
Fernando Fernandez Mancera <[email protected]> Mon, 13 Jul 2026 16:57:02 +0200
| Newsgroups | gmane.linux.network.bridge |
|---|---|
| Message-ID | <d126eb95-4f57-43f7-8cde-31f201d3dad0__25047.4135553063$1783955756$gmane$org@suse.de> |
On 7/13/26 4:22 PM, Arnd Bergmann wrote: > On Mon, Jul 13, 2026, at 16:00, Fernando Fernandez Mancera wrote: >> 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. > > Ok > >>> 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.