Message ID | a64af194-3c5f-b38e-70ce-3c3f69a844d9@nxp.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id B2A355683; Fri, 7 Oct 2016 15:40:26 +0200 (CEST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0055.outbound.protection.outlook.com [104.47.32.55]) by dpdk.org (Postfix) with ESMTP id DBD2A567A for <dev@dpdk.org>; Fri, 7 Oct 2016 15:40:24 +0200 (CEST) Received: from BY2PR03CA074.namprd03.prod.outlook.com (10.141.249.47) by SN1PR0301MB2016.namprd03.prod.outlook.com (10.163.226.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Fri, 7 Oct 2016 13:40:23 +0000 Received: from BL2FFO11FD058.protection.gbl (2a01:111:f400:7c09::160) by BY2PR03CA074.outlook.office365.com (2a01:111:e400:2c5d::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16 via Frontend Transport; Fri, 7 Oct 2016 13:40:23 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=nxp.com; 6wind.com; dkim=none (message not signed) header.d=none; 6wind.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BL2FFO11FD058.mail.protection.outlook.com (10.173.161.126) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.629.5 via Frontend Transport; Fri, 7 Oct 2016 13:40:22 +0000 Received: from [10.232.14.87] ([10.232.14.87]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id u97DeJRi020206; Fri, 7 Oct 2016 06:40:20 -0700 To: <david.marchand@6wind.com>, <thomas.monjalon@6wind.com> References: <1475847187-28967-1-git-send-email-shreyansh.jain@nxp.com> CC: <dev@dpdk.org> From: Shreyansh Jain <shreyansh.jain@nxp.com> Message-ID: <a64af194-3c5f-b38e-70ce-3c3f69a844d9@nxp.com> Date: Fri, 7 Oct 2016 19:11:15 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1475847187-28967-1-git-send-email-shreyansh.jain@nxp.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131203212228506510; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.158.2; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(1110001)(1109001)(339900001)(189002)(24454002)(377454003)(199003)(87936001)(83506001)(586003)(68736007)(305945005)(92566002)(5001770100001)(77096005)(7846002)(2950100002)(50466002)(6666003)(69596002)(230700001)(85426001)(104016004)(356003)(33646002)(8936002)(23746002)(76176999)(19580405001)(36756003)(65956001)(64126003)(8676002)(81166006)(19580395003)(626004)(5660300001)(86362001)(81156014)(4001350100001)(11100500001)(106466001)(31696002)(65826007)(105606002)(4326007)(47776003)(97736004)(65806001)(189998001)(31686004)(2906002)(54356999)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB2016; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD058; 1:btZY8Xb1ObuDtszB4E5aLLiMOsjOxF4FrQ6MO4JDQcWrsOSbrymWC1+ulcCP0JtdgIVGqPN/LdEI8yJ5SEr8N+Vcovxi2+iWFCoZg1LNXx8QDLpstAXdGsMK47kOIs0vSGFvMyat/kiYecpDUaMpjtNWV9zRNEpyssEEs5DUN3KaL17SmUSAxlABslrs3zdZziX8RGd/f/PiiSGkxGOmwCm+Exe3+gcym9LhS5itVXo+1Gjj8V1zd1XrOplJ1JtWP3hjhpQkYDfx7nAN6EiPZoMWVPD5F0yuCykwCC0hWB951s4ajv0cunKa00PXNJXnJlKxBtUHTF3h2FVEAz9NgeStkfg1YcooMc1EiAHIh8HShDtRzcsWng+thjbt5i9thF+CHAh4T3cDIWPH7SyrYHS3DX4dnCBnIAav7PCYTsGfy55l/Rnn4P5EZwScE3R2raaaXNtXsWe/IVBwNnY9b7+MhIFxTMrem0oKASUQ8Mq3bsoOyx2+lUVKkBmBi0J4I8h0MsvnvmLLQiaddP1rPA0SQBl+i0jS4d4+xmqVMz3cqbcncawcxNNk7yrvxvuRbOYfvmbo5AOmO2Go4791qw== X-MS-Office365-Filtering-Correlation-Id: 252ba05a-5ebf-4ea1-338e-08d3eeb77cbc X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB2016; 2:cz92cuHkb9oDrX6z+bxfjNLkIdIMsdckPir49ohABfdoynOuZ6Efwa004NythbRDW4L3UAplFv7vg4mRZUS8Sxlu1u0l4BGaui/GTlX3pk+qQ0vIGntfa0rkYUHKN6bBZHPBA0fciVjpChGineO31wN3las6KDbC1tB4TBmktHB51O5M19YgENBbI6Rq3crx7Uz8tALmydaFNoAxYcRzvQ==; 3:ttPO4jPI91LPV3/veNzI/1AsIjvjW/LkiGbjTbOq6fzaIW33UEXoO+vNauhasNde5YgsgvyWg+p5ozBtJ3Rjxiu6uVO7tlEG1UZk/JkjQZye85TZ1i8BjWOYH/yS0bk4mJnTXUjXH6tfeRC5rnUaIgz1RaF3ULeBuRREADQ8TiH2Ns0ZFLuOAn4PLbC8bkch6rpTFR02g4UYGEu8bAJ3ocASunCfirAWzRiQ4kaqrCPv0Ngn3PZdCUFbFrhNYANy X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB2016; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB2016; 25:ODCLUpKHvbpT27U4cY7EEmuSAmXh9Ho+f0W2Y2Xnh7tDYLNj/k9tr2vWuqo9nR7zQg+DFUNOmq6N+IxXa5MNh85Gori5AMTbYaIdigQTYk3Z6hj/p/5kdp/mUAbyJI0jaUn8Btyih/FEeJ0lBhQBrgRRUKr9xStqd7GMHH3uM6S4+dz8jNpQpXz3rd7To+RWZasCUdHik1jpK+43Ry2giTc+PUC5kkYkkEqlHhQkHBbHJosnyZo7cf/9qaD8X/XmxNnAYRqali558pyW+yxSeixfs1Z/k0g7An+RcD2u7fc/irlf3VIk5nYQHGvLctNESKvuA2mZM0w4r4VlNBKz9DqEXEXQtgK1QZGtZlcSXUTjWUz9xcGb2LqzxJwZ2QP5AGXDdsRlxdqzGv8hbmuvkdkfJuqpz84jAAt58f3N+ujugZgxmh+jvXHt0Ubc5P8AJKUIwH3A59/Piky7e2mSdx/QPnqM7G4rzNXPFpQbijG+JdtRRp+NmhvUuLZYxzISACO0VBqLFWpFCPiBuf6iWymqZL1ExDK3VIO/bZ3R9e2I9AS/CVoqC3QDApDReiz+8eDiNEq77OgfUKLJ605rHfH1xf8hKtvqHI+9uTbb5CYIdLYoYGG5/GrOLvHKOx+3Zq1rYzs7/vJSvIceewBBc2YyeB6MnhjujQpUvjOjkxqEnsTs699Q0PI1EsA11s7zshrzMkrV3ahNOA2mHbdxk2z1hIDhbMILuavcLrCkcP9YVU33t39jJYdhWyokpXlA X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB2016; 31:cHPjERn+Y3JptvbK4iH0XO4o+FkjnIkLwvGW2jRx+ULPBoT/keXyWYEWa6khVRX0zo8TK2845aaDjYPybhwWrbgVXjeffuSA3itAsvhy5J/GJSlFuI4bJtIWld7UWZChUuBoqJbRZ1+FUp2C8OEOoX0HiDuJwcPxj6Vrr8k4Q0vBf6yAeK0p7xBAhShQF0L/agpjRzJX2kWwuvF+Epx4BFchsmeusDG1i2kjFtpZOzq+ZqFNeBUTmPIWkETHOdqF; 4:6TKjKiYzsI3F3+noCGEbx8sm+KFI9Ox4svzB32AjtOffriuiCa1R5M+Tsz/nPXN6ig/WBww+OZtdZ/xGz13gFKryE6RkLIs47BfFEw4tkiUsWEucQ616ucg5/Di6YwLn6usZTRTsNRZl8koX8Za8E/DPrNwrem4bTjmp3B4dl1tXkgZqH8+Rxi52ChT9u/eFbGM2vgmhre99cWmGUl60jCyrGzrtfbwr2cWpOt3pM2ZPJIoZfl/Kx2u6c3/JVhkUq0+dnIiFmSEXFzSIyqrjxLdOw3viWGawYnQovd7JZrafyPIIwAFTbOPilf172ViURZ5gnv4Y9o64QvYxFG32bqcNzQ2bomRfyFc7m711Q+YvSqBA3YMNZAbMHShr3eP1Qqv0JBB4OH5JrCeex513oFq2iQ8TGE1kIlb2eluBCJ5T9P2MSoir1EDN53kDrhASHdDc0/30HM9BBSr/kXcGUQNjymmfRokXuHkdRV7GHO90AiJQyvy5lo/gNi8bf03fI3C55Eav9oliSFIeJ+lFkb+NBVZbSo6f12dFMjHxfTKrpJzQJJFVqktLcZwrVPzygc7LdWJeKztNyVtnADaS7w== X-Microsoft-Antispam-PRVS: <SN1PR0301MB2016B70F4D089BAB9D6F1DF690C60@SN1PR0301MB2016.namprd03.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(155532106045638); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13024025)(13015025)(13023025)(8121501046)(13017025)(13018025)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0301MB2016; BCL:0; PCL:0; RULEID:(400006); SRVR:SN1PR0301MB2016; X-Forefront-PRVS: 0088C92887 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR0301MB2016; 23:nbmmKgUwH+iy0cG8OfjUVdT12+NqTW9CXB0?= =?Windows-1252?Q?89xTCiRLMtc0NmDJZe1nIYFkYTQHh0BS17WvYCIa9DyhSCTIU0v5b1Qc?= =?Windows-1252?Q?eD6eCsLs3p9cJPmuN8y7keaiyBlUrVxXrNafiYULX+v5v0CFsbCB6VFu?= =?Windows-1252?Q?z4oWE68QfgnnGJiUgUri+2b6Wv79iwv6uOqxylsALGkGcXNNGqbY9Dau?= =?Windows-1252?Q?lQS59SXt97jpQJBkEaoRRALTJjfurUvHTaCP0dNn1sHTTRGqetsUrMK6?= =?Windows-1252?Q?G6taJK6oSCsbzFXACasJ6dlb6cAoYSjJkiZt8O92Fx8J03QaQrqDIsLe?= =?Windows-1252?Q?7q4fPWludV5t1nOddXQu9O6oS/61DEhXFyDYFfVPExlSQ34Xh9y9u+k9?= =?Windows-1252?Q?g382GTRzJeh3icqviwfGqbmShlEW3ZvSFFaJI1K/Pype+4uQoODoKgrR?= =?Windows-1252?Q?QmhDjjvaqv7WzENeB5MPksCWirmLg28z2IgrK8wJhdfQdYAGBNoeGkaL?= =?Windows-1252?Q?QnrUIhbCxsSNvkC6mVIMY9ZZWnS7vwQV2GLdhHBahEJj/nQRbvhkjLuV?= =?Windows-1252?Q?KVtacby0tB2oVS06hlOxCeUmAXD/eDquiR5RyQD0zRW6Ip/x2LEtv1Jh?= =?Windows-1252?Q?UL8ikaolRLgvTMMtD+2I+txbwLpUJswNPZlpx8ru5eZX5nSDowp8eE4J?= =?Windows-1252?Q?mJimBnPnmF+sRx6C9YjYUVrNfFlbXMDD2zlNI9l0VP2CiJCNd/8ygCyX?= =?Windows-1252?Q?UA0zfuJswvWQhu7qCsDRcwzQ0qVAIKQ6U/yJARvdeSZ2Gp3EzAuKmuHc?= =?Windows-1252?Q?/G+b44U/fOWzEcYeMEJYHCYfFyHaLglnp/PkpTtm+VIVqIUSkKV0Jp7T?= =?Windows-1252?Q?97I+pDk+7CJAfVMSeUd4Vldaw/az/GyR3Ftv/uMsfblJO9s1CD0ijAMb?= =?Windows-1252?Q?hkypfvv2zDHl17hnC2AURkjlkatDdJkeYqwDi8Z3/1IxXehDqC3v29iR?= =?Windows-1252?Q?XY71RNau1sTECduu6Yp7RpMG93gu8ZQ01lTDEihfTuoGBpKi82HVczKl?= =?Windows-1252?Q?c4x9tiDP6pr/uNa3zexumGzXguz8h0HeGkyXwMKUhd7Q/HhybJX4WToZ?= =?Windows-1252?Q?Im6fo3R0gsYbUfK4fNWn9zKRdEXTB5LjXtWFwQINbC14E6um7aeqzhJe?= =?Windows-1252?Q?mVXr+PN5K/wi9DElBxjpNDDkkZH93y0shqRTSZctfYSKHS0c0xSs6FyL?= =?Windows-1252?Q?fSQrA4ooqmFzDTD4nvbAwswWN8Y32XGXCPah4olg6xhO16NRnOEQ8qy1?= =?Windows-1252?Q?Mg2LK/eRpjn8kZFOAJ8gBT7hEbG9vFqJ13wCLByMdHlxb8l684ijqljb?= =?Windows-1252?Q?Vy3ZcZn1O3U/S1y50SrcSZN7oklF/+vP3iAGAtT4E4jlNQNYQEQEb4yV?= =?Windows-1252?Q?pYXa3n1H+SOEmds2bgch8ClbKXEFkT+Wp41jd77j1uStwTteg55xFifu?= =?Windows-1252?Q?kxWE67ag=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB2016; 6:Ux6JC8xZvkRYEpei1efc47piR3s96NNny/EOkcN4Y9K24i6hMMDMG/VNb9dWMDxcirA4Vosu0DLsGpLyvFAoI1RNfOOSGr1W7OvBagQ69e6zoVwi9g3AfF4BYhP1AsefXl8ndbtfsL5FXDpC/uokoGiAZv0dLWGiqdBTFzEl5zTQ+e+WC+xiGN8eMxwC1m0Dv+l0f8fxakK2noqkPPETH4rYRn1eqc+4WFJnhL7KrbLGZjN5ihU6hPZcoSJR6wbPxqeCnlsUOUN9iFs9H92zbCxtX+7+kzzaBJiNhU5JXTyt8BSz93y/2FfI7Q9R7hGD; 5:MDsNZhi8gAjNuiPlvEaVakF5tLKCX2a2g7ec8t+wTMAhIR5sPmUG7J/L79Ng+4RSmDFY0z3xH6p2j3X/Ui7ukBDesdJbjwsidD7IdDQ15Nw9EEZT0cay6zH6kY3MX+OMcRGvrlEZK2dc1p5rhkwkIF4ULgNJvV+6T1s1leCZLH0QPmJsTbx68QkQdin7/+6b; 24:0le2tyj2hctyCErrzcwxiw/BDZPmrjpyjHpm69CPfrcylbmH4cJWfEShbF/DLm4xAzfu5xT2VLEVnfvXIJ3UhG9EopQQYjfU34zPwx/WD+A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB2016; 7:tzQTkIdbDF9GwNGrTawK/Syo9o9ngrM/Q7HZH7/S4+tVS/s0WzyHFLR9UJmc3imbj84IvJdL6gQGxDfIV3BEV/aGE/NmF9Yf2VD5Slw6wUXT1mkXJaGWeImXDkrH1yTzLV6JodMLPux1dixkd2bBiHa7CrYUSMniaWKZMKwqZFnOgPWJBZxCmu2Gwsepr0xY/hCO826RCQ8BAXMz2/iRZPKUDREf6jiSRHSdTrtLiI3ANaQEDUpHaoL0C7bnvjdksLAsGCRiz+pheRk0X83Z6nHdM54o76dtt/QekKt5vX5QdfFOJ1RlNFGoJCwo/yMHYk0FRAnm+fYVOzaj7Aebyw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2016 13:40:22.6322 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2016 Subject: Re: [dpdk-dev] [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL 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> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Shreyansh Jain
Oct. 7, 2016, 1:41 p.m. UTC
Hi David, Thomas, On Friday 07 October 2016 07:03 PM, Shreyansh Jain wrote: > DRIVER_REGISTER_PCI -> EAL_REGISTER_PCI > DRIVER_REGISTER_PCI_TABLE -> EAL_REGISTER_PCI_TABLE > > Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com> > --- > doc/guides/prog_guide/dev_kit_build_system.rst | 2 +- > drivers/crypto/qat/rte_qat_cryptodev.c | 4 ++-- > drivers/net/bnx2x/bnx2x_ethdev.c | 8 ++++---- > drivers/net/bnxt/bnxt_ethdev.c | 4 ++-- > drivers/net/cxgbe/cxgbe_ethdev.c | 4 ++-- > drivers/net/e1000/em_ethdev.c | 4 ++-- > drivers/net/e1000/igb_ethdev.c | 8 ++++---- > drivers/net/ena/ena_ethdev.c | 4 ++-- > drivers/net/enic/enic_ethdev.c | 4 ++-- > drivers/net/fm10k/fm10k_ethdev.c | 4 ++-- > drivers/net/i40e/i40e_ethdev.c | 4 ++-- > drivers/net/i40e/i40e_ethdev_vf.c | 4 ++-- > drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++++---- > drivers/net/mlx4/mlx4.c | 2 +- > drivers/net/mlx5/mlx5.c | 2 +- > drivers/net/nfp/nfp_net.c | 4 ++-- > drivers/net/qede/qede_ethdev.c | 8 ++++---- > drivers/net/szedata2/rte_eth_szedata2.c | 4 ++-- > drivers/net/thunderx/nicvf_ethdev.c | 4 ++-- > drivers/net/virtio/virtio_ethdev.c | 2 +- > drivers/net/vmxnet3/vmxnet3_ethdev.c | 4 ++-- > lib/librte_eal/common/include/rte_dev.h | 2 +- > lib/librte_eal/common/include/rte_pci.h | 2 +- > 23 files changed, 48 insertions(+), 48 deletions(-) > [...] Ideally there should be a another patch like below as part of the series: --->8--- --->8--- But unfortunately, my build system complained about this. (and I stopped short of sending this patch). The output of compilation after this patch is something like: --->8--- CC eal_pci_vfio.o PMDINFO eal_pci_vfio.o.pmd.c /bin/sh: 1: /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk-pmdinfogen: not found /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: recipe for target 'eal_pci_vfio.o' failed --->8--- I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro as well? I am not very well versed with how PMDINFO is linking with the build system so any hints/insight into this would be really helpful. One I get more clarity on this, I will push a new version of this patch. - Shreyansh
Comments
2016-10-07 19:11, Shreyansh Jain: > --- a/mk/internal/rte.compile-pre.mk > +++ b/mk/internal/rte.compile-pre.mk > @@ -87,7 +87,7 @@ endif > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > $(PMDINFO_GEN) && \ > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > --->8--- > CC eal_pci_vfio.o > PMDINFO eal_pci_vfio.o.pmd.c > /bin/sh: 1: > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk-pmdinfogen: > not found > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > recipe for target 'eal_pci_vfio.o' failed > --->8--- > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? Every files are scanned for the pattern. > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > as well? Probably. That's another argument in favor of good prefixes. I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ > > I am not very well versed with how PMDINFO is linking with the build > system so any hints/insight into this would be really helpful. > > One I get more clarity on this, I will push a new version of this patch. Thanks
On Fri, Oct 07, 2016 at 03:51:44PM +0200, Thomas Monjalon wrote: > 2016-10-07 19:11, Shreyansh Jain: > > --- a/mk/internal/rte.compile-pre.mk > > +++ b/mk/internal/rte.compile-pre.mk > > @@ -87,7 +87,7 @@ endif > > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > > $(PMDINFO_GEN) && \ > > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > > > --->8--- > > CC eal_pci_vfio.o > > PMDINFO eal_pci_vfio.o.pmd.c > > /bin/sh: 1: > > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk-pmdinfogen: > > not found > > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > > recipe for target 'eal_pci_vfio.o' failed > > --->8--- > > > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > > Every files are scanned for the pattern. > > > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > > as well? > > Probably. > That's another argument in favor of good prefixes. > I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ Thats what we had, about 4 changes to this macro ago, and yes, that made alot more sense, to grep on a more complete version of the macro name to ensure a unique match. You might just look for the regex EAL_REGISTER_VDEV|EAL_REGISTER_PCI with grep -E Neil > > > > I am not very well versed with how PMDINFO is linking with the build > > system so any hints/insight into this would be really helpful. > > > > One I get more clarity on this, I will push a new version of this patch. > > Thanks >
Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, October 07, 2016 7:22 PM > To: Shreyansh Jain <shreyansh.jain@nxp.com> > Cc: david.marchand@6wind.com; dev@dpdk.org > Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL > > 2016-10-07 19:11, Shreyansh Jain: > > --- a/mk/internal/rte.compile-pre.mk > > +++ b/mk/internal/rte.compile-pre.mk > > @@ -87,7 +87,7 @@ endif > > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > > $(PMDINFO_GEN) && \ > > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > > > --->8--- > > CC eal_pci_vfio.o > > PMDINFO eal_pci_vfio.o.pmd.c > > /bin/sh: 1: > > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- > pmdinfogen: > > not found > > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > > recipe for target 'eal_pci_vfio.o' failed > > --->8--- > > > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > > Every files are scanned for the pattern. Sorry, I should have been clearer in my statement. I meant, I didn't think eal_pci_vfio.o had anything of interest for the PMD tool and hence the mk files would have skipped over it in absence of a match. I understand that PMDINFO would run on all files. > > > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > > as well? > > Probably. > That's another argument in favor of good prefixes. > I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ I thought of EAL_PMD_REGISTER_* but dropped it because for PCI_TABLE like macros, the name got really long (EAL_PMD_REGISTER_PCI_TABLE()). Anyways, I will use RTE_PMD_REGISTER_* now and send another version. > > > > I am not very well versed with how PMDINFO is linking with the build > > system so any hints/insight into this would be really helpful. > > > > One I get more clarity on this, I will push a new version of this patch. > > Thanks - Shreyansh
Hi Neil, > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Friday, October 07, 2016 7:48 PM > To: Thomas Monjalon <thomas.monjalon@6wind.com> > Cc: Shreyansh Jain <shreyansh.jain@nxp.com>; david.marchand@6wind.com; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/3] eal/drivers: prefix driver REGISTER > macros with EAL > > On Fri, Oct 07, 2016 at 03:51:44PM +0200, Thomas Monjalon wrote: > > 2016-10-07 19:11, Shreyansh Jain: > > > --- a/mk/internal/rte.compile-pre.mk > > > +++ b/mk/internal/rte.compile-pre.mk > > > @@ -87,7 +87,7 @@ endif > > > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > > > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > > > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > > > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > > > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > > > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > > > $(PMDINFO_GEN) && \ > > > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > > > > > --->8--- > > > CC eal_pci_vfio.o > > > PMDINFO eal_pci_vfio.o.pmd.c > > > /bin/sh: 1: > > > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- > pmdinfogen: > > > not found > > > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > > > recipe for target 'eal_pci_vfio.o' failed > > > --->8--- > > > > > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > > > > Every files are scanned for the pattern. > > > > > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > > > as well? > > > > Probably. > > That's another argument in favor of good prefixes. > > I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ > Thats what we had, about 4 changes to this macro ago, and yes, that made alot > more sense, to grep on a more complete version of the macro name to ensure a > unique match. You might just look for the regex > EAL_REGISTER_VDEV|EAL_REGISTER_PCI with grep -E Thanks. I will use this grep. > > Neil > > > > > > > > > I am not very well versed with how PMDINFO is linking with the build > > > system so any hints/insight into this would be really helpful. > > > > > > One I get more clarity on this, I will push a new version of this patch. > > > > Thanks > > - Shreyansh
On Sat, Oct 08, 2016 at 01:00:59PM +0000, Shreyansh Jain wrote: > Hi Thomas, > > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Friday, October 07, 2016 7:22 PM > > To: Shreyansh Jain <shreyansh.jain@nxp.com> > > Cc: david.marchand@6wind.com; dev@dpdk.org > > Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL > > > > 2016-10-07 19:11, Shreyansh Jain: > > > --- a/mk/internal/rte.compile-pre.mk > > > +++ b/mk/internal/rte.compile-pre.mk > > > @@ -87,7 +87,7 @@ endif > > > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > > > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > > > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > > > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > > > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > > > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > > > $(PMDINFO_GEN) && \ > > > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > > > > > --->8--- > > > CC eal_pci_vfio.o > > > PMDINFO eal_pci_vfio.o.pmd.c > > > /bin/sh: 1: > > > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- > > pmdinfogen: > > > not found > > > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > > > recipe for target 'eal_pci_vfio.o' failed > > > --->8--- > > > > > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > > > > Every files are scanned for the pattern. > > Sorry, I should have been clearer in my statement. > I meant, I didn't think eal_pci_vfio.o had anything of interest for the PMD tool and hence the mk files would have skipped over it in absence of a match. > I understand that PMDINFO would run on all files. > Thats incorrect, the Makefile does a REGEX search for appropriate registration macros that imply the need for pmdinfo to run. If its running on an inappropriate file its because your new macros inadvertently match the current regex, hence my suggestion that the regex should be tuned to be more specific Neil > > > > > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > > > as well? > > > > Probably. > > That's another argument in favor of good prefixes. > > I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ > > I thought of EAL_PMD_REGISTER_* but dropped it because for PCI_TABLE like macros, the name got really long (EAL_PMD_REGISTER_PCI_TABLE()). > Anyways, I will use RTE_PMD_REGISTER_* now and send another version. > > > > > > > I am not very well versed with how PMDINFO is linking with the build > > > system so any hints/insight into this would be really helpful. > > > > > > One I get more clarity on this, I will push a new version of this patch. > > > > Thanks > > - > Shreyansh >
On Monday 10 October 2016 06:26 PM, Neil Horman wrote: > On Sat, Oct 08, 2016 at 01:00:59PM +0000, Shreyansh Jain wrote: >> Hi Thomas, >> >>> -----Original Message----- >>> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >>> Sent: Friday, October 07, 2016 7:22 PM >>> To: Shreyansh Jain <shreyansh.jain@nxp.com> >>> Cc: david.marchand@6wind.com; dev@dpdk.org >>> Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL >>> >>> 2016-10-07 19:11, Shreyansh Jain: >>>> --- a/mk/internal/rte.compile-pre.mk >>>> +++ b/mk/internal/rte.compile-pre.mk >>>> @@ -87,7 +87,7 @@ endif >>>> PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c >>>> PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c >>>> PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ >>>> -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ >>>> +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ >>>> echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ >>>> $(PMDINFO_GEN) && \ >>>> echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ >>>> >>>> --->8--- >>>> CC eal_pci_vfio.o >>>> PMDINFO eal_pci_vfio.o.pmd.c >>>> /bin/sh: 1: >>>> /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- >>> pmdinfogen: >>>> not found >>>> /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: >>>> recipe for target 'eal_pci_vfio.o' failed >>>> --->8--- >>>> >>>> I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? >>> >>> Every files are scanned for the pattern. >> >> Sorry, I should have been clearer in my statement. >> I meant, I didn't think eal_pci_vfio.o had anything of interest for the PMD tool and hence the mk files would have skipped over it in absence of a match. >> I understand that PMDINFO would run on all files. >> > Thats incorrect, the Makefile does a REGEX search for appropriate registration > macros that imply the need for pmdinfo to run. If its running on an > inappropriate file its because your new macros inadvertently match the current > regex, hence my suggestion that the regex should be tuned to be more specific Agree. Thats is what I wanted to clarify as stated below: "...EAL_REGISTER_* (macro name has changed since) is matching EAL_REGISTER_TAILQ..". As for 'more specific' match - I did suggest [2] a longer more specific version but Thomas had a different view point [1]. You can have a look at [2] and let me know your suggestion or if that is wrong. [1] http://dpdk.org/ml/archives/dev/2016-October/048425.html [2] http://dpdk.org/ml/archives/dev/2016-October/048407.html > > Neil > >>> >>>> Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro >>>> as well? >>> >>> Probably. >>> That's another argument in favor of good prefixes. >>> I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ >> >> I thought of EAL_PMD_REGISTER_* but dropped it because for PCI_TABLE like macros, the name got really long (EAL_PMD_REGISTER_PCI_TABLE()). >> Anyways, I will use RTE_PMD_REGISTER_* now and send another version. >> >>>> >>>> I am not very well versed with how PMDINFO is linking with the build >>>> system so any hints/insight into this would be really helpful. >>>> >>>> One I get more clarity on this, I will push a new version of this patch. >>> >>> Thanks >> >> - >> Shreyansh >> > - Shreyansh
2016-10-11 12:06, Shreyansh Jain: > On Monday 10 October 2016 06:26 PM, Neil Horman wrote: > > On Sat, Oct 08, 2016 at 01:00:59PM +0000, Shreyansh Jain wrote: > >> Hi Thomas, > >> > >>> -----Original Message----- > >>> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > >>> Sent: Friday, October 07, 2016 7:22 PM > >>> To: Shreyansh Jain <shreyansh.jain@nxp.com> > >>> Cc: david.marchand@6wind.com; dev@dpdk.org > >>> Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL > >>> > >>> 2016-10-07 19:11, Shreyansh Jain: > >>>> --- a/mk/internal/rte.compile-pre.mk > >>>> +++ b/mk/internal/rte.compile-pre.mk > >>>> @@ -87,7 +87,7 @@ endif > >>>> PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > >>>> PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > >>>> PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > >>>> -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > >>>> +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > >>>> echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > >>>> $(PMDINFO_GEN) && \ > >>>> echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > >>>> > >>>> --->8--- > >>>> CC eal_pci_vfio.o > >>>> PMDINFO eal_pci_vfio.o.pmd.c > >>>> /bin/sh: 1: > >>>> /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- > >>> pmdinfogen: > >>>> not found > >>>> /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > >>>> recipe for target 'eal_pci_vfio.o' failed > >>>> --->8--- > >>>> > >>>> I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > >>> > >>> Every files are scanned for the pattern. > >> > >> Sorry, I should have been clearer in my statement. > >> I meant, I didn't think eal_pci_vfio.o had anything of interest for the PMD tool and hence the mk files would have skipped over it in absence of a match. > >> I understand that PMDINFO would run on all files. > >> > > Thats incorrect, the Makefile does a REGEX search for appropriate registration > > macros that imply the need for pmdinfo to run. If its running on an > > inappropriate file its because your new macros inadvertently match the current > > regex, hence my suggestion that the regex should be tuned to be more specific > > Agree. Thats is what I wanted to clarify as stated below: > "...EAL_REGISTER_* (macro name has changed since) is matching > EAL_REGISTER_TAILQ..". > > As for 'more specific' match - I did suggest [2] a longer more specific > version but Thomas had a different view point [1]. You can have a look > at [2] and let me know your suggestion or if that is wrong. > > [1] http://dpdk.org/ml/archives/dev/2016-October/048425.html > [2] http://dpdk.org/ml/archives/dev/2016-October/048407.html I do not have a different point of view :) We need to be more specific than EAL_REGISTER_*. And RTE_PMD_REGISTER_* is specific enough. That's all :)
On Tue, Oct 11, 2016 at 12:06:27PM +0530, Shreyansh Jain wrote: > On Monday 10 October 2016 06:26 PM, Neil Horman wrote: > > On Sat, Oct 08, 2016 at 01:00:59PM +0000, Shreyansh Jain wrote: > > > Hi Thomas, > > > > > > > -----Original Message----- > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > Sent: Friday, October 07, 2016 7:22 PM > > > > To: Shreyansh Jain <shreyansh.jain@nxp.com> > > > > Cc: david.marchand@6wind.com; dev@dpdk.org > > > > Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL > > > > > > > > 2016-10-07 19:11, Shreyansh Jain: > > > > > --- a/mk/internal/rte.compile-pre.mk > > > > > +++ b/mk/internal/rte.compile-pre.mk > > > > > @@ -87,7 +87,7 @@ endif > > > > > PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c > > > > > PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c > > > > > PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ > > > > > -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ > > > > > +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ > > > > > echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ > > > > > $(PMDINFO_GEN) && \ > > > > > echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \ > > > > > > > > > > --->8--- > > > > > CC eal_pci_vfio.o > > > > > PMDINFO eal_pci_vfio.o.pmd.c > > > > > /bin/sh: 1: > > > > > /home/shreyansh/build/DPDK/02_dpdk/x86_64-native-linuxapp-gcc/app/dpdk- > > > > pmdinfogen: > > > > > not found > > > > > /home/shreyansh/build/DPDK/02_dpdk/mk/internal/rte.compile-pre.mk:138: > > > > > recipe for target 'eal_pci_vfio.o' failed > > > > > --->8--- > > > > > > > > > > I don't think PMDINFO should be running on eal_pci_vfio file. Isn't it? > > > > > > > > Every files are scanned for the pattern. > > > > > > Sorry, I should have been clearer in my statement. > > > I meant, I didn't think eal_pci_vfio.o had anything of interest for the PMD tool and hence the mk files would have skipped over it in absence of a match. > > > I understand that PMDINFO would run on all files. > > > > > Thats incorrect, the Makefile does a REGEX search for appropriate registration > > macros that imply the need for pmdinfo to run. If its running on an > > inappropriate file its because your new macros inadvertently match the current > > regex, hence my suggestion that the regex should be tuned to be more specific > > Agree. Thats is what I wanted to clarify as stated below: "...EAL_REGISTER_* > (macro name has changed since) is matching EAL_REGISTER_TAILQ..". > > As for 'more specific' match - I did suggest [2] a longer more specific > version but Thomas had a different view point [1]. You can have a look at > [2] and let me know your suggestion or if that is wrong. > > [1] http://dpdk.org/ml/archives/dev/2016-October/048425.html > [2] http://dpdk.org/ml/archives/dev/2016-October/048407.html > Right, so I'm on the same page as Thomas, in that the "RTE_PMD_REGISTER_.*(" regex is sufficient in the current state. However, your patches are changing the registration macros from something that is sufficiently unique for pmdinfo to detect to something that collides with an inappropriate match (the EAL_REGISTER_TAILQ macro), and so you have to make the regex more specific. This also begs the question in my mind, is it really worth changing the macro? I really don't think it is. The registration macros are pretty descriptive as they stand, and have already changed 3 or 4 times in the last 6 months, which suggests to me that any change here is really just churn more than meaningful change. You can make the argument that the name might be more in line with the library its implemented in or what not, but in truth, its easy to understand what the macros do (in their previous or current incantations), and any change that just makes them the same as other macros in their naming is really more trouble than its worth. Neil Neil > > > > Neil > > > > > > > > > > > Is it because EAL_REGISTER_* is matching EAL_REGISTER_TAILQ like macro > > > > > as well? > > > > > > > > Probably. > > > > That's another argument in favor of good prefixes. > > > > I think you should use RTE_DRIVER_REGISTER_ or better, RTE_PMD_REGISTER_ > > > > > > I thought of EAL_PMD_REGISTER_* but dropped it because for PCI_TABLE like macros, the name got really long (EAL_PMD_REGISTER_PCI_TABLE()). > > > Anyways, I will use RTE_PMD_REGISTER_* now and send another version. > > > > > > > > > > > > > I am not very well versed with how PMDINFO is linking with the build > > > > > system so any hints/insight into this would be really helpful. > > > > > > > > > > One I get more clarity on this, I will push a new version of this patch. > > > > > > > > Thanks > > > > > > - > > > Shreyansh > > > > > > > - > Shreyansh >
2016-10-11 09:38, Neil Horman: > This also begs the question in my mind, is it really worth changing the macro? > I really don't think it is. The registration macros are pretty descriptive as > they stand, and have already changed 3 or 4 times in the last 6 months, which > suggests to me that any change here is really just churn more than meaningful > change. You can make the argument that the name might be more in line with the > library its implemented in or what not, but in truth, its easy to understand > what the macros do (in their previous or current incantations), and any change > that just makes them the same as other macros in their naming is really more > trouble than its worth. Neil, the long term goal is to stop having some identifiers which do not start with RTE_ in our exported .h files. I think it is a reasonable policy, for a library, to live in a well defined namespace.
On Tue, Oct 11, 2016 at 03:57:29PM +0200, Thomas Monjalon wrote: > 2016-10-11 09:38, Neil Horman: > > This also begs the question in my mind, is it really worth changing the macro? > > I really don't think it is. The registration macros are pretty descriptive as > > they stand, and have already changed 3 or 4 times in the last 6 months, which > > suggests to me that any change here is really just churn more than meaningful > > change. You can make the argument that the name might be more in line with the > > library its implemented in or what not, but in truth, its easy to understand > > what the macros do (in their previous or current incantations), and any change > > that just makes them the same as other macros in their naming is really more > > trouble than its worth. > > Neil, the long term goal is to stop having some identifiers which do not > start with RTE_ in our exported .h files. > I think it is a reasonable policy, for a library, to live in a well defined > namespace. > I don't disagree that a consistent namespace is a nice thing, only that we've had 3 changes to these macros in the last few months, none of which have really moved us toward that goal. At least we can agree that the EAL_ macro being proposed isn't the right thing to do regardless of motivation :) Neil
On Tuesday 11 October 2016 08:27 PM, Neil Horman wrote: > On Tue, Oct 11, 2016 at 03:57:29PM +0200, Thomas Monjalon wrote: >> 2016-10-11 09:38, Neil Horman: >>> This also begs the question in my mind, is it really worth changing the macro? >>> I really don't think it is. The registration macros are pretty descriptive as >>> they stand, and have already changed 3 or 4 times in the last 6 months, which >>> suggests to me that any change here is really just churn more than meaningful >>> change. You can make the argument that the name might be more in line with the >>> library its implemented in or what not, but in truth, its easy to understand >>> what the macros do (in their previous or current incantations), and any change >>> that just makes them the same as other macros in their naming is really more >>> trouble than its worth. >> >> Neil, the long term goal is to stop having some identifiers which do not >> start with RTE_ in our exported .h files. >> I think it is a reasonable policy, for a library, to live in a well defined >> namespace. Understood and agreed. >> > > I don't disagree that a consistent namespace is a nice thing, only that we've > had 3 changes to these macros in the last few months, none of which have really > moved us toward that goal. > > At least we can agree that the EAL_ macro being proposed isn't the right thing > to do regardless of motivation :) Macro proposed by this patch is not EAL_*. Thomas had already suggested that change for v1; v3 changes it to RTE_PMD_REGISTER_*. --->8--- DRIVER_REGISTER_PCI -> RTE_PMD_REGISTER_PCI DRIVER_REGISTER_PCI_TABLE -> RTE_PMD_REGISTER_PCI_TABLE DRIVER_REGISTER_VDEV -> RTE_PMD_REGISTER_VDEV DRIVER_REGISTER_PARAM_STRING -> RTE_PMD_REGISTER_PARAM_STRING DRIVER_EXPORT_* -> RTE_PMD_EXPORT_* --->8--- - Shreyansh
diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk index a42ef03..a91c265 100644 --- a/mk/internal/rte.compile-pre.mk +++ b/mk/internal/rte.compile-pre.mk @@ -87,7 +87,7 @@ endif PMDINFO_GEN = $(RTE_SDK_BIN)/app/dpdk-pmdinfogen $@ $@.pmd.c PMDINFO_CC = $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@ -PMDINFO_TO_O = if grep -q 'DRIVER_REGISTER_.*(.*)' $<; then \ +PMDINFO_TO_O = if grep 'EAL_REGISTER_.*(.*)' $<; then \ echo "$(if $V,$(PMDINFO_GEN), PMDINFO $@.pmd.c)" && \ $(PMDINFO_GEN) && \ echo "$(if $V,$(PMDINFO_CC), CC $@.pmd.o)" && \