From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 603A8C5FA for ; Fri, 29 Jan 2016 11:10:38 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C7CE68C1AF; Fri, 29 Jan 2016 10:10:37 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-4-87.ams2.redhat.com [10.36.4.87]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0TAAZs1000908; Fri, 29 Jan 2016 05:10:36 -0500 To: Thomas Monjalon References: <1451357606-117892-1-git-send-email-ziye.yang@intel.com> <3789219.tMSa25XPXU@xps13> <56AB2EFF.5000804@redhat.com> <5614874.AxjIHfzHGV@xps13> From: Panu Matilainen Message-ID: <56AB3A9B.80500@redhat.com> Date: Fri, 29 Jan 2016 12:10:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5614874.AxjIHfzHGV@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: dev@dpdk.org, Ziye Yang 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 10:10:38 -0000 On 01/29/2016 11:34 AM, Thomas Monjalon wrote: > 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 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 >>>>>> >>>>>> 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 Using separate headers is also good. Optimally both? :) >>> 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. Cool, the rest is just details then. > 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. That's one possibility. Another way to achieve essentially the same is to make rte_eal_driver_register() symbol version follow the DPDK version, in which case a driver built for another version will fail at dlopen() already. > And we should change or remove the .so version which never change for > most of drivers. Yup, so-versioning DSOs which do not offer any ABI is kinda pointless. - Panu -