Hi Gaetan, On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote:
[2017-06-06 22:58:01 +0200] Baptiste Jonglez:
Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible.
There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one.
We already have an official linux package in [core] which is very well maintained and works great for 99% of our users, so I'd really like if you tried to explain why we need another variant and why the AUR is not suitable for it anymore.
At that point, Multipath TCP is mostly useful to researchers and tinkerers, because both ends of a TCP connection need to run the modified kernel (otherwise, it just falls back to regular TCP). However, I still think it would be useful in [community]: 1) One nice use-case is link aggregation, where you basically tunnel traffic over a Multipath TCP connection. You may want to build such a tunnelling system with Arch. 2) Not everybody has the resources to build a kernel (time, CPU, memory, disk...) 3) It is good to have kernel diversity in our repositories. For instance, I had a laptop that couldn't go to sleep with the kernels from [core] (either linux or linux-lts), but it worked with linux-mptcp. This is really not the main goal of having linux-mptcp in [community], but it's a nice side-effect. By the way, the kernel is completely stable, I have been using it on a daily basis (on my laptop) since a few years. At the beginning of the project in ~2014, there were occasional kernel panics, but not anymore.
As you're aware, we've had another package (linux-grsec) with a user base certainly much larger than linux-multipath come and go because upstream went another direction and nobody had the resources to fork it. I'd really like our packages to enjoy some level of support and not just go to [community] "because they can" and get dropped just as fast. What could you tell us about linux-multipath on that front?
When talking about "some level of support", do you mean whether the upstream project is active? The project has one main developer, 2 to 3 additional developers, and several small contributors (including myself). I think nobody is working full-time on it, though. Regarding activity, major releases happen when the project is rebased on a more recent kernel version and sufficiently tested: - v0.86 released 2013-03-07, based on linux 3.5 - v0.87 released 2013-07-25, based on linux 3.10 - v0.88 released 2013-10-30, based on linux 3.11 - v0.89 released 2014-10-12, based on linux 3.14 - v0.90 released 2015-09-02, based on linux 3.18 - v0.91 released 2016-06-21, based on linux 4.1 - v0.92 released 2017-06-04, based on linux 4.4 So, I would say the project is active and focused on the long term. There have been minor releases in-between these major releases, to integrate bugfixes and update to latest stable kernel. For instance, v0.91.2 was based on linux 4.1.35. Baptiste