From mboxrd@z Thu Jan  1 00:00:00 1970
From: Panu Matilainen <pmatilai@redhat.com>
Subject: Re: [PATCH v3 0/2] slow data path communication between
 DPDK port and Linux
Date: Wed, 16 Mar 2016 17:03:54 +0200
Message-ID: <56E975DA.8030300@redhat.com>
References: <1455858349-14639-1-git-send-email-ferruh.yigit@intel.com>
 <56E934E5.4080905@intel.com> <56E95C6B.1000004@redhat.com>
 <11855450.AeS7qhTG6k@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org,
 David Marchand <david.marchand@6wind.com>,
 Helin Zhang <helin.zhang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id 233435588
 for <dev@dpdk.org>; Wed, 16 Mar 2016 16:03:57 +0100 (CET)
In-Reply-To: <11855450.AeS7qhTG6k@xps13>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 03/16/2016 03:58 PM, Thomas Monjalon wrote:
> 2016-03-16 15:15, Panu Matilainen:
>> What I really would like to see is a clear policy regarding kernel
>> modules in DPDK. I certainly am in no position to dictate one, and
>> that's why I've been asking questions and throwing around crazy (or not)
>> ideas around the topic.
>
> I think the consensus is to avoid new kernel module,
> but allow them in a staging directory while being discussed upstream.

To me the more interesting question is: what happens after that?
As in, if upstream says no, does it mean axe from dpdk, no ifs and buts? 
If accepted upstream, does a version of the module still live within 
dpdk codebase (for example to provide the version for older kernel 
versions, I dont see that as unreasonable at all)?


> About the existing out-of-tree kernel modules, we must continue trying
> to obsolete them with upstream work.

Agreed.

>
> If you feel the consensus must be clearly stated and acked,
> please send a patch for doc/guides/contributing/design.rst.

I'll be happy to, once we have a clear consensus on what the policy 
actually is.

	- Panu -