From: Florian Fainelli <f.fainelli@gmail.com>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>,
"David Miller" <davem@davemloft.net>
Cc: Linux NetDev <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/2] net: enable IPv6 iff IPv4
Date: Mon, 1 Apr 2019 14:52:58 -0700 [thread overview]
Message-ID: <d79e9ab3-a2ef-eed8-2afa-20bc243ba0aa@gmail.com> (raw)
In-Reply-To: <CANP3RGdoZtETWgoeUTemjFoNVSkzY-WKhn=MErRvdQBj=HsPKw@mail.gmail.com>
On 4/1/19 2:02 PM, Maciej Żenczykowski wrote:
>> Things are modular because we don't unilaterally make decisions for
>> people on this level.
>
> We do unilaterally make various decisions - some of them quite big in scope.
> Although perhaps not this one.
>
>> This is why I'm very much not too motivated to integrate changes like
>> this, even though I understand the motivation and simplifications this
>> would enable.
>
>> I mean, who the heck are we to tell someone that because they make
>> some tiny device meant for an isolated ipv4 environment that they
>> _MUST_ have ipv6 also built into their kernels?
>
> One of the major reasons why ipv6 is seeing such slow adoption is because
> people keep manufacturing ipv4 only devices. It's just a stupid
> network attached
> sensor, but it doesn't work on your network because it doesn't support ipv6...
> and as a result you need to keep around legacy ipv4 support.
>
> Why should the manufacturers be allowed to tell me how to run my network?
>
> These small devices are unlikely to be even running a 5.2+ kernel for another
> half decade or more.
>
> ie. we're talking about hardware that'll come to market 3-4 years from now,
> at the earliest, probably later, since no one updates the
> kernel/software on these
> devices after they initially start shipping.
>
> If they truly need something so tiny and so ipv6 unsupporting, they
> can simply run 5.1 or older.
You can't use your own argument both ways and complain that people
design devices that are never upgraded and then just give them another
argument for not updating because IPv6 simply makes them make an
unacceptable decision which could be either of:
- creating another attack surface they had not thought about initially
- making their memory budget explode to the point where a new kernel
becomes out of the equation, period
- the product is simply not meeting the requirements of *not* supporting
IPv6 (granted it could be a stupid requirement, yet be one)
> It's not like we'll delete the source code for older versions of Linux.
No, but it is another roadblock to upstreaming changes for your embedded
device if you need to make a few tweaks here and there. And given the
direction you want to go later on, it won't be as simple as a revert of
your patches to go back to hypothetical pre-5.1 behavior.
>
> ---
>
> Perhaps just making ipv6 a boolean instead of a tristate would be acceptable?
>
> That would get rid of most of the craziness with supporting loading
> ipv6 as a module,
> the checks for is this function null, etc. and we could still move all
> the fields into
> the main ip struct just surrounded by #ifdef IPV6
>
Are you seeing a performance problem where having IPv6 be built-in and
all code being reachable would help, or are you trying to improve the
maintenance burden, or is it something else?
--
Florian
next prev parent reply other threads:[~2019-04-01 21:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 19:44 [PATCH 1/2] net: enable IPv6 iff IPv4 Maciej Żenczykowski
2019-04-01 19:44 ` [PATCH 2/2] net: configs - remove CONFIG_IPV6 references Maciej Żenczykowski
2019-04-01 20:31 ` [PATCH 1/2] net: enable IPv6 iff IPv4 David Miller
2019-04-01 21:02 ` Maciej Żenczykowski
2019-04-01 21:10 ` David Miller
2019-04-01 21:52 ` Florian Fainelli [this message]
2019-04-01 21:37 ` Florian Fainelli
2019-04-01 21:54 ` David Miller
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=d79e9ab3-a2ef-eed8-2afa-20bc243ba0aa@gmail.com \
--to=f.fainelli@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=zenczykowski@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).