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
signature.asc
Description: PGP signature
