© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
4d1350f
(Get the code!)
Hi Juerg,
> The rationale for the change is that we want to modularize as much as possible for the raspi kernel because of limited RAM on that platform.
Thank you for the explanation. It makes sense for features that are not often used.
When I looked at the source code [1], I didn't find where CONFIG_IPV6 was forced to be used as a module, I could only find references where it should be forced to be inlined instead.
> That change by itself is not considered a regression unless you're loosing functionality. Are you?
Yes, we are loosing functionality here: we can no longer use MPTCP [2] with IPv6, only with IPv4.
But I guess the big question is to have CONFIG_IPV6 as a module or not, right?
When we looked at upstreaming MPTCP, we checked if there was a reason to support CONFIG_IPV6 set as a module. These discussions around the subject with net maintainers ended up with the conclusion that it was not needed to support CONFIG_IPV6=m because in short, "today's Internet is IPv6". IPV6 module will very likely be used and loaded in RAM anyway: if the device has network enabled (I guess it has in most cases), it will use IPv6 except explicitly configured not to. IPv6 will be used at least for the localhost device (::1) plus the link local addresses of each interface.
Adding to that that there is an additional cost to have it as a module each time it has to be used, I don't think it is a good idea to have CONFIG_IPV6=m in "generic" deployments.
[1] https:/
[2] https:/