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.