Bruce Richardson [off-list ref] writes:

On Wed, Feb 14, 2018 at 10:08:34AM -0800, Stephen Hemminger wrote:

quoted

On Wed, 14 Feb 2018 11:44:15 +0000
Bruce Richardson [off-list ref] wrote:

quoted

On Wed, Feb 14, 2018 at 10:54:44AM +0000, Luca Boccassi wrote:

quoted

On Wed, 2018-02-14 at 11:38 +0100, Maxime Coquelin wrote:  

quoted

On 02/14/2018 11:31 AM, Luca Boccassi wrote:  

quoted

On Wed, 2018-02-14 at 00:58 +0100, Thomas Monjalon wrote:  

quoted

31/01/2018 16:27, Stephen Hemminger:  

quoted

Notify users of upcoming change in kernel requirement.
Encourage users to use current LTS kernel version.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

--- +* linux: Linux kernel version 3.2 (which is the current

minimum required +  version for the DPDK) will be end of life
in May 2018.  Therefore the planned +  minimum required kernel
version for DPDK 18.5 will be next oldest Long +  Term Stable
(LTS) version which is 3.10. The recommended kernel version is
+  the latest LTS kernel which currently is 4.14.  

We could print a warning at EAL init if kernel version does not
satisfy the minimal requirement.

Acked-by: Thomas Monjalon <redacted>  

Note that 3.10 is dead as well since last year (as I discovered
with immense joy when I had to backport meltdown fixes...), the
next LTS in 3.16 which will be maintained until 04/2020.
  

In this case we should differentiate upstream Kernel versions from
downstream ones. For example, RHEL7/CentOS7 are based on v3.10 ans
still maintained.  

Ubuntu does 3.13 as well - I think the problem is that if we want to
support distro-specific LTS kernel versions, we need volunteers to do
the work for them :-)

--   

I think our kernel support plans need to be two-fold:

1) we need to support a minimum "kernel.org" kernel version, which is
what the deprecation notice is about.
2) we also will be supporting LTS distributions, e.g. I would expect us to
always support the latest RHEL, so that should be noted explicitly in the
GSG IMHO.

For distributions, we need to have a maintainer. Ideally, from the vendor or
project doing the distribution.

I actually don't think that's really necessary. It's very rare for
changes to LTS distributions to cause us problems, it's far more common
to have issues the other way round. Because of that, it's working fine
just refusing to apply patches that break the build on our supported
distributions.

I tend to agree with Bruce.  What is specifically being requested?  From
a downstream perspective, we ship dpdk and applications enabled with
dpdk.

We support those applications, and that version of the library
(including performing bugfixes, etc).  In addition, we do our best to
support upstream efforts (eg. working with vendors, working with
applications, working with users, contributing bug fixes, etc).

Is there something different that needs to happen?  Happy to help - just
need to know what helping means :)