From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
 by dpdk.org (Postfix) with ESMTP id 70151C60C
 for <dev@dpdk.org>; Fri, 29 Jan 2016 10:35:56 +0100 (CET)
Received: by mail-wm0-f47.google.com with SMTP id p63so59834680wmp.1
 for <dev@dpdk.org>; Fri, 29 Jan 2016 01:35:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id:organization:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding
 :content-type; bh=nZrgE/P1vSaJxbOhw0qTcmm4KgNEm+fE5JZ1xlbKono=;
 b=QtikJ8Z50fIl0oBAo4YhTeD1bd3v6z4iwkGTdEwSVlm/VdbmbheJ7HiN7PHiV6fwl2
 Fq+BisYwyCZRQT7muKb+1zCSY7Ak2RJXnmZEitYRpP0x11qsn7FgtbLmFA4d3f18aPHw
 QwIILAgnlcWWNC767VdzpwNCgrB1ByeeB3Xb8mwY3wS1GF7rzGE+z3X56NgDwbOmZsvu
 6omJV933kJxyEgEC8vikwSWG8sxaRZV2HGXc5TCbtVdR8pR/k3qEn70gWW+T9W5a50w0
 X5iF9t21JS0jtVX66aPSR5LnhUTGSfAUQzOjPHyiu+oqsHtguEIG2dst6tY7xrA9XzQA
 DMwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=nZrgE/P1vSaJxbOhw0qTcmm4KgNEm+fE5JZ1xlbKono=;
 b=jsHvyzWM/l84NYyiDIp52wL8GS01FO/p6rp6bR7ZG6NI5KjEv4A7V6mzd+/NB3IKqV
 UGqnYVhpz7nw5jtkGqKBJxJWqCaxRd0W+Jsdk22mbXmtMH2MdAzX35vxIOWaIXIo4e0Y
 f81iqcB6mugd29FrASIokgTXWXg9yOAaHvtjp4FWYaR/w857kXUX0pe/Dy+vPd4we6kk
 yBZRetCZ46QDrEJQu463k58eRC49pCUIPSrchH4bEv3kzUkY8sRAIIuImPjIZ0W/LS+P
 4ax3+KDFj5YPcT3zAxxZD8eGuQLUQoofvQReLgWEwhyZTu9lfqRdjGc07jg2Xg0QO2oo
 HyMQ==
X-Gm-Message-State: AG10YORHqDsquDhE9D90NCPP2t4ji3W/m/cwS681qAHEatAScmpFtJILg2QPVvWraRWoYElX
X-Received: by 10.28.23.73 with SMTP id 70mr7439339wmx.37.1454060156241;
 Fri, 29 Jan 2016 01:35:56 -0800 (PST)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
 by smtp.gmail.com with ESMTPSA id c185sm6640238wma.5.2016.01.29.01.35.55
 (version=TLSv1/SSLv3 cipher=OTHER);
 Fri, 29 Jan 2016 01:35:55 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Panu Matilainen <pmatilai@redhat.com>
Date: Fri, 29 Jan 2016 10:34:43 +0100
Message-ID: <5614874.AxjIHfzHGV@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <56AB2EFF.5000804@redhat.com>
References: <1451357606-117892-1-git-send-email-ziye.yang@intel.com>
 <3789219.tMSa25XPXU@xps13> <56AB2EFF.5000804@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org, Ziye Yang <ziye.yang@intel.com>
Subject: Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Fri, 29 Jan 2016 09:35:56 -0000

2016-01-29 11:21, Panu Matilainen:
> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
> > 2016-01-13 14:22, Panu Matilainen:
> >> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> >>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> >>>> On Tue, 29 Dec 2015 10:53:26 +0800
> >>>> Ziye Yang <ziye.yang@intel.com> wrote:
> >>>>
> >>>>> This patch is used to add the class_id support
> >>>>> for pci_probe since some devices need the class_info
> >>>>> (class_code, subclass_code, programming_interface)
> >>>>>
> >>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> >>>>
> >>>> Since rte_pci is exposed to application this breaks the ABI.
> >>>
> >>> But applications are not going to be defining rte_pci_ids values internally, are
> >>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
> >>> need to be concerned about?
> >>
> >> There might not be applications using it but drivers are ABI consumers
> >> too - think of 3rd party drivers and such.
> >
> > Drivers are not ABI consumers in the sense that ABI means
> > Application Binary Interface.
> > We are talking about drivers interface here.
> > When establishing the ABI policy we were discussing about applications only.
> 
> Generally speaking an ABI is an interface between two program (or 
> software if you like) modules, its not specific to "applications". 
> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see 
> it does only talk about applications, but an ABI consumer can also be 
> another library. A driver calling rte_malloc() is just as much 
> librte_eal ABI consumer as anything else.
> 
> Now, I understand that drivers use and need interface(s) that 
> applications have no use for or simply cannot use, and those interfaces 
> could be subject to different policies. As an extreme example, the Linux 
> kernel has two isolated ABIs, one is the userland system call interface 
> which is guaranteed to stay forever and the other is kernel module 
> interface, guarantees nothing at all.
> 
> In DPDK the difference is far muddier than that since all the interfaces 
> live in common, versioned userland DSOs. So if there are two different 
> interfaces following two different policies, it's all the more important 
> to clearly document them. One simple way could be using a different 
> prefix than rte_.

Good suggestion. Or we can simply have different files with a clear notice
in their headers and in the versioning doc.
It was well split in rte_cryptodev_pmd.h

> > I agree we must allow 3rd party drivers but there is no good reason
> > to try to upgrade DPDK without upgrading/porting the external drivers.
> > If someone does not want to release its driver and keep upgrading DPDK,
> > it is acceptable IMHO to force an upgrade of its driver.
> 
> Note that I've no particular sympathy for 3rd party drivers as such. 
> What I *do* care about is that breakage is made explicit, as in drivers 
> built for an incompatible version refuse to load at all, instead of 
> silently corrupting memory etc.

OK I agree.
Anyway the ABI versionning does not cover the structure changes.
What about making a DPDK version check when registering a driver?
So a binary driver would be clearly bound to a DPDK version.
And we should change or remove the .so version which never change for
most of drivers.