From: Krzysztof Kozlowski <krzk@kernel.org>
To: Vlastimil Babka <vbabka@suse.com>,
"Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Fernando Fernandez Mancera <fmancera@suse.de>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, dsahern@kernel.org
Subject: Re: [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs
Date: Mon, 16 Mar 2026 12:17:02 +0100 [thread overview]
Message-ID: <56ad8ce8-a085-4f67-b4ae-25e5f28c3e51@kernel.org> (raw)
In-Reply-To: <97d85c42-5ef3-4912-abb9-8d4fe6fa54df@suse.com>
On 16/03/2026 12:10, Vlastimil Babka wrote:
> On 3/16/26 11:33, Krzysztof Kozlowski wrote:
>> On 16/03/2026 11:24, Lorenzo Stoakes (Oracle) wrote:
>>>
>>> If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
>>> giving an unnecessarily mean, dismissive and frankly embarassing response
>>> like the above.
>>
>> Calling something legacy in this thread is not really appropriate
>> because it is diminishing its important or requirements.
>>
>> Till we support given hardware, we are supposed to consider its
>> requirements. If you do not consider these requirements, then you do not
>> consider that hardware as worth being supported and this means you
>> should first propose patch to remove that hardware.
>
> I don't think it's so binary. AFAIU (and recall also Linus saying that) it's
> ok to make things less optimal for older/less common hardware, if that's the
> cost to make the kernel better for the major ones. So that's why we're e.g.
> discussing removing CONFIG_HIMEM which could limit how much physical RAM
> some 32bit architectures can use. Or we can have new features e.g. 64-bit only.
>
> We can call that older/less common hardware "legacy" or "museum" or
> whatever, I wouldn't say it's diminishing it, just stating a fact.
Yes. Amiga was the first thing I poked to discuss affecting less capable
hardware. But we could also talk about ARM 32-bit, which is not yet
considered "legacy" because new hardware is being manufactured and sold.
Legacy in a meaning we do consider its requirements/support.
>
> Of course the devil is in the details so that probably to some extent
> depends on what exactly you mean as "requirements" above. AFAIU the
> conclusion here was already that ipv6=m isn't consired one for Amiga to
> stay, and it's enough to have ipv6=n there.
>
Yes, and other replies (parallel threads) also provide context and
arguments why most, not all though, distros don't even use IPV6=m, while
they are making everything else modules by default.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-03-16 11:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 2:19 [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 01/10 net-next] ipv6: convert CONFIG_IPV6 to built-in only and clean up Kconfigs Fernando Fernandez Mancera
2026-03-09 10:24 ` Krzysztof Kozlowski
2026-03-10 19:40 ` Kolbjørn Barmen
2026-03-10 19:58 ` Arnd Bergmann
2026-03-10 20:35 ` Sabrina Dubroca
2026-03-10 21:18 ` Bjørn Mork
2026-03-10 22:18 ` Arnd Bergmann
2026-03-11 8:21 ` Geert Uytterhoeven
2026-03-09 2:19 ` [PATCH 02/10 net-next] ipv6: replace IS_BUILTIN(CONFIG_IPV6) with IS_ENABLED(CONFIG_IPV6) Fernando Fernandez Mancera
2026-04-01 12:52 ` David Woodhouse
2026-03-09 2:19 ` [PATCH 03/10 net-next] ipv6: remove dynamic ICMPv6 sender registration infrastructure Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 04/10 net-next] ipv6: prepare headers for ipv6_stub removal Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 05/10 net-next] drivers: net: drop ipv6_stub usage and use direct function calls Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 06/10 net-next] ipv4: " Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 07/10 net-next] net: convert remaining ipv6_stub users to " Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 08/10 net-next] bpf: remove ipv6_bpf_stub completely and use " Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 09/10 net-next] ipv6: remove ipv6_stub infrastructure completely Fernando Fernandez Mancera
2026-03-09 2:19 ` [PATCH 10/10 net-next] netfilter: remove nf_ipv6_ops and use direct function calls Fernando Fernandez Mancera
2026-03-09 10:22 ` [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs Krzysztof Kozlowski
2026-03-09 10:26 ` Krzysztof Kozlowski
2026-03-09 23:18 ` Jakub Kicinski
2026-03-10 20:02 ` Krzysztof Kozlowski
2026-03-10 21:42 ` Jakub Kicinski
2026-03-10 22:15 ` Fernando Fernandez Mancera
2026-03-09 11:33 ` David Woodhouse
2026-03-09 11:38 ` Fernando Fernandez Mancera
2026-03-09 12:43 ` Krzysztof Kozlowski
2026-03-09 12:58 ` Daniel Borkmann
2026-03-09 13:02 ` Krzysztof Kozlowski
2026-03-09 13:14 ` Fernando Fernandez Mancera
2026-03-16 10:24 ` Lorenzo Stoakes (Oracle)
2026-03-16 10:33 ` Krzysztof Kozlowski
2026-03-16 10:50 ` Lorenzo Stoakes (Oracle)
2026-03-16 10:58 ` Krzysztof Kozlowski
2026-03-16 11:10 ` Vlastimil Babka
2026-03-16 11:17 ` Krzysztof Kozlowski [this message]
2026-03-09 13:07 ` Fernando Fernandez Mancera
2026-03-09 14:47 ` Jakub Kicinski
2026-03-09 15:10 ` Fernando Fernandez Mancera
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=56ad8ce8-a085-4f67-b4ae-25e5f28c3e51@kernel.org \
--to=krzk@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fmancera@suse.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vbabka@suse.com \
/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.