From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 30680A0096 for ; Fri, 12 Apr 2019 19:25:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C144F1B3AA; Fri, 12 Apr 2019 19:25:57 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id A6AC81B29A; Fri, 12 Apr 2019 19:25:51 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2019 10:25:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,342,1549958400"; d="scan'208";a="163917011" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.46]) ([10.237.221.46]) by fmsmga001.fm.intel.com with ESMTP; 12 Apr 2019 10:25:48 -0700 To: "Ananyev, Konstantin" , Stephen Hemminger , "Richardson, Bruce" Cc: David Christensen , "thomas@monjalon.net" , "arybchenko@solarflare.com" , "dev@dpdk.org" , "radhika.chirra@ibm.com" , "stable@dpdk.org" References: <1554927376-93022-1-git-send-email-drc@linux.vnet.ibm.com> <20190410210017.GA742@bricha3-MOBL.ger.corp.intel.com> <20190410160818.78855564@shemminger-XPS-13-9360> <88e75c95-b2d3-ca28-b4f3-d27d0c7d6e99@intel.com> <2601191342CEEE43887BDE71AB9772580148A96EA6@irsmsx105.ger.corp.intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJVBBMBAgA/AhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgBYhBNI2U4dCLsKE45mBx/kz60PfE2EfBQJbughWBQkHwjOGAAoJEPkz60Pf E2Eft84QAIbKWqhgqRfoiw/BbXbA1+qm2o4UgkCRQ0yJgt9QsnbpOmPKydHH0ixCliNz1J8e mRXCkMini1bTpnzp7spOjQGLeAFkNFz6BMq8YF2mVWbGEDE9WgnAxZdi0eLY7ZQnHbE6AxKL SXmpe9INb6z3ztseFt7mqje/W/6DWYIMnH3Yz9KzxujFWDcq8UCAvPkxVQXLTMpauhFgYeEx Nub5HbvhxTfUkapLwRQsSd/HbywzqZ3s/bbYMjj5JO3tgMiM9g9HOjv1G2f1dQjHi5YQiTZl 1eIIqQ3pTic6ROaiZqNmQFXPsoOOFfXF8nN2zg8kl/sSdoXWHhama5hbwwtl1vdaygQYlmdK H2ueiFh/UvT3WG3waNv2eZiEbHV8Rk52Xyn2w1G90lV0fYC6Ket1Xjoch7kjwbx793Kz/RfQ rmBY8/S4DTGn3oq3dMdQY+b6+7VMUeLMMh2CXYO9ErkOq+qNTD1IY+cBAkXnaDbQfz0zbste ZGWH74FAZ9nCpDOqbRTrBL42aMGhfOWEyeA1x7+hl6JZfabBWAuf4nnCXuorKHzBXTrf7u7p fXsKQClWRW77PF1VmzrtKNVSytQAmlCWApQIw20AarFipXmVdIjHmJPU611WoyxZPb4JTOxx 5cv9B+nr/RIB+v5dcStyHCCwO1be7nBDdCgd4F6kTQPLuQINBFfWTL4BEACnNA29e8TarUsB L5n6eLZHXcFvVwNLVlirWOClHXf44o2KnN3ww+eBEmKVfEFo9MSuGDNHS8Zw1NiGMYxLIUgd U6gGrVVs/VrQWL82pbMk6jCj98N+BXIri+6K1z+AImz7ax7iF1kDgRAnFWU0znWWBgM2mM8Y gDjcxfXk4sCKnvf6Gjo08Ey5zmqx7dekAKU2EEp8Q1EJY3jbymLdZWRP4AFFMTS1rGMk0/tt v71NBg1GobCcbNfn9chK/jhqxYhAJqq86RdJQkt3/9x1U1Oq0vXCt4JVVHmkxePtUiuWTTt+ aYlUAsKYZsWvncExvw77x2ArYDmaK0yfjh37wp0lY7DOJHFxoyT8tyWZlLci/VMRG2Ja33xj 0CN4C1yBg+QDeV3QFxQo42iA/ykdXPUR3ezmsND3XKvVLTC4DNb3V/EZQ7jBj64+bEK0VW4G B31VP00ApNQvSoczsIOAKdk97RNbpmPw6q10ILIB+9T1xbnFYzshzGF17oC0/GENIHATx8vZ masOZoDiOZQpeneLgnFE9JfzhLTxv6wNZcc/HLXRQVTkDsQr8ERtkAoHCf1E5+b5Yr7pfnE4 YuhET746o25S53ELUYPIs49qoJsEJL34/oexMfPGyPIlrbufiNyty5jc/1MRwUlhJlJ5IOHy ZUa+6CLR7GdImusFkPJUJwARAQABiQI8BBgBAgAmAhsMFiEE0jZTh0IuwoTjmYHH+TPrQ98T YR8FAlu6CHAFCQXE7zIACgkQ+TPrQ98TYR9nXxAAqNBgkYNyGuWUuy0GwDQCbu3iiMyH1+D7 llafPcK4NYy1Z4AYuVwC9nmLaoj+ozdqS3ncRo57ncRsKEJC46nDJJZYZ5LSJVn63Y3NBF86 lxQAgjj2oyZEwaLKtKbAFsXL43jv1pUGgSvWwYtDwHITXXFQto9rZEuUDRFSx4sg9OR+Q6/6 LY+nQQ3OdHlBkflzYMPcWgDcvcTAO6yasLEUf7UcYoSWTyMYjLB4QuNlXzTswzGVMssJF/vo V8lD1eqqaSUWG3STF6GVLQOr1NLvN5+kUBiEStHFxBpgSCvYY9sNV8FS6N24CAWMBl+10W+D 2h1yiiP5dOdPcBDYKsgqDD91/sP0WdyMJkwdQJtD49f9f+lYloxHnSAxMleOpyscg1pldw+i mPaUY1bmIknLhhkqfMmjywQOXpac5LRMibAAYkcB8v7y3kwELnt8mhqqZy6LUsqcWygNbH/W K3GGt5tRpeIXeJ25x8gg5EBQ0Jnvp/IbBYQfPLtXH0Myq2QuAhk/1q2yEIbVjS+7iowEZNyE 56K63WBJxsJPB2mvmLgn98GqB4G6GufP1ndS0XDti/2K0o8rep9xoY/JDGi0n0L0tk9BHyoP Y7kaEpu7UyY3nVdRLe5H1/MnFG8hdJ97WqnPS0buYZlrbTV0nRFL/NI2VABl18vEEXvNQiO+ vM8= Message-ID: <0c9b3ee9-4bc4-4ab0-7678-4827538dda3a@intel.com> Date: Fri, 12 Apr 2019 18:25:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772580148A96EA6@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] ethdev: missing typecast from void in eth_dev_pci_specific_init X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 4/12/2019 6:15 PM, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit >> Sent: Friday, April 12, 2019 6:09 PM >> To: Stephen Hemminger ; Richardson, Bruce >> Cc: David Christensen ; thomas@monjalon.net; arybchenko@solarflare.com; dev@dpdk.org; >> radhika.chirra@ibm.com; stable@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] ethdev: missing typecast from void in eth_dev_pci_specific_init >> >> On 4/11/2019 12:08 AM, Stephen Hemminger wrote: >>> On Wed, 10 Apr 2019 22:00:18 +0100 >>> Bruce Richardson wrote: >>> >>>> On Wed, Apr 10, 2019 at 03:16:16PM -0500, David Christensen wrote: >>>>> The function eth_dev_pci_specific_init is missing a typecast to >>>>> (struct rte_pci_device *) for the input argument bus_device. >>>>> >>>>> Cc: stable@dpdk.org >>>>> >>>>> Signed-off-by: David Christensen >>>>> Tested-by: Radhika Chirra >>>>> --- >>>>> lib/librte_ethdev/rte_ethdev_pci.h | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/lib/librte_ethdev/rte_ethdev_pci.h b/lib/librte_ethdev/rte_ethdev_pci.h >>>>> index 23257e9..a325311 100644 >>>>> --- a/lib/librte_ethdev/rte_ethdev_pci.h >>>>> +++ b/lib/librte_ethdev/rte_ethdev_pci.h >>>>> @@ -72,7 +72,7 @@ >>>>> >>>>> static inline int >>>>> eth_dev_pci_specific_init(struct rte_eth_dev *eth_dev, void *bus_device) { >>>>> - struct rte_pci_device *pci_dev = bus_device; >>>>> + struct rte_pci_device *pci_dev = (struct rte_pci_device *)bus_device; >>>>> >>>> >>>> Is this needed for building some C++ apps that are including the header >>>> file (directly, or indirectly), because for pure C, "void *" types should >>>> be assignable to any other pointer type without casting? >>>> >>>> /Bruce >>> >>> Another example of Why the Hell is this inline? >>> >> >> It has been done inline intentionally at the time as far as remember, this >> header is for drivers not for applications, it has helper functions. >> >> The common code from drivers related to the bus put into header files, so the >> code itself belongs to drivers not ethdev and reduces duplicates in them. > > Ok that's the common code used by the drivers... > But why it still can't be in .c file? When it is in .c file, it will be either in ethdev library, single location in .c file and binary file, but location is not exactly right, because code belongs to drivers. Or code should be in .c files of each drivers, this will be code duplication. Having in .h file makes code in single place, but when compiled code will be in each driver object file/ library. Of course it works when put into a .c file in ehtdev, but bus (pci and vdev) related code are not belongs to ethdev library and I believe shouldn't be part of ethdev binary. And those bus helper headers are only for drivers to include, so having inline shouldn't be a problem at all because there is not stability concern in that interface.