From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 662891B2C7 for ; Thu, 15 Feb 2018 10:26:06 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 01:26:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,516,1511856000"; d="scan'208";a="204326656" Received: from bricha3-mobl3.ger.corp.intel.com ([10.252.19.81]) by fmsmga005.fm.intel.com with SMTP; 15 Feb 2018 01:26:02 -0800 Received: by (sSMTP sendmail emulation); Thu, 15 Feb 2018 09:26:01 +0000 Date: Thu, 15 Feb 2018 09:26:00 +0000 From: Bruce Richardson To: Stephen Hemminger Cc: Luca Boccassi , Maxime Coquelin , Thomas Monjalon , dev@dpdk.org Message-ID: <20180215092559.GA11448@bricha3-MOBL3.ger.corp.intel.com> References: <20180131152709.13853-1-stephen@networkplumber.org> <2393289.cND9ge7AvX@xps> <1518604285.4059.14.camel@debian.org> <470fdbc6-7280-1523-da8b-91fda8fafbcf@redhat.com> <1518605684.4059.16.camel@debian.org> <20180214114415.GA1880@bricha3-MOBL3.ger.corp.intel.com> <20180214100834.54cfcf6b@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180214100834.54cfcf6b@xeon-e3> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: [dpdk-dev] [PATCH] doc: add kernel version deprecation notice X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 09:26:06 -0000 On Wed, Feb 14, 2018 at 10:08:34AM -0800, Stephen Hemminger wrote: > On Wed, 14 Feb 2018 11:44:15 +0000 > Bruce Richardson wrote: > > > On Wed, Feb 14, 2018 at 10:54:44AM +0000, Luca Boccassi wrote: > > > On Wed, 2018-02-14 at 11:38 +0100, Maxime Coquelin wrote: > > > > > > > > On 02/14/2018 11:31 AM, Luca Boccassi wrote: > > > > > On Wed, 2018-02-14 at 00:58 +0100, Thomas Monjalon wrote: > > > > > > 31/01/2018 16:27, Stephen Hemminger: > > > > > > > Notify users of upcoming change in kernel requirement. > > > > > > > Encourage users to use current LTS kernel version. > > > > > > > > > > > > > > Signed-off-by: Stephen Hemminger > > > > > > > --- +* 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 > > > > > > > > > > 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. /Bruce