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 3972DC656 for ; Fri, 29 Jan 2016 13:47:27 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9D03D8EA34; Fri, 29 Jan 2016 12:47:26 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-4-87.ams2.redhat.com [10.36.4.87]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0TClOoJ031679; Fri, 29 Jan 2016 07:47:24 -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> <56AB3A9B.80500@redhat.com> From: Panu Matilainen Message-ID: <56AB5F5B.6000800@redhat.com> Date: Fri, 29 Jan 2016 14:47:23 +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: <56AB3A9B.80500@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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 12:47:27 -0000 On 01/29/2016 12:10 PM, Panu Matilainen wrote: > 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. Thinking about this a bit more, symbol versioning doesn't cut it because its not always used (static linkakage) and I guess we should cover that too. Another similar possibility that blocks it at dlopen() level is to munge the actual function name to carry a version, so it becomes something like rte_eal_driver_register_v230() and later _v240() etc. AFAICS its only ever invoked via PMD_REGISTER_DRIVER() so the calling details can conveniently be hidden there. - Panu -