From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 0A2BA11D4 for ; Thu, 7 Jul 2016 13:40:34 +0200 (CEST) Received: from [2606:a000:111b:40ed:7aac:c0ff:fec2:933b] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1bL7ec-0004wL-Ip; Thu, 07 Jul 2016 07:39:48 -0400 Date: Thu, 7 Jul 2016 07:39:27 -0400 From: Neil Horman To: "De Lara Guarch, Pablo" Cc: "dev@dpdk.org" , "Richardson, Bruce" , Thomas Monjalon , Stephen Hemminger , Panu Matilainen Message-ID: <20160707113927.GA26064@hmsreliant.think-freely.org> References: <1465494421-6210-1-git-send-email-nhorman@tuxdriver.com> <1466189185-21952-1-git-send-email-nhorman@tuxdriver.com> <1466189185-21952-3-git-send-email-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro usage 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: Thu, 07 Jul 2016 11:40:34 -0000 On Thu, Jul 07, 2016 at 11:00:59AM +0000, De Lara Guarch, Pablo wrote: > > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > > Sent: Friday, June 17, 2016 7:46 PM > > To: dev@dpdk.org > > Cc: Neil Horman; Richardson, Bruce; Thomas Monjalon; Stephen Hemminger; > > Panu Matilainen > > Subject: [dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro > > usage > > > > Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it. > > The > > addition of a name argument creates a token that can be used for subsequent > > macros in the creation of unique symbol names to export additional bits of > > information for use by the pmdinfogen tool. For example: > > > > PMD_REGISTER_DRIVER(ena_driver, ena); > > > > registers the ena_driver struct as it always did, and creates a symbol > > const char this_pmd_name0[] __attribute__((used)) = "ena"; > > > > which pmdinfogen can search for and extract. The subsequent macro > > > > DRIVER_REGISTER_PCI_TABLE(ena, ena_pci_id_map); > > > > creates a symbol const char ena_pci_tbl_export[] __attribute__((used)) = > > "ena_pci_id_map"; > > > > Which allows pmdinfogen to find the pci table of this driver > > > > Using this pattern, we can export arbitrary bits of information. > > > > pmdinfo uses this information to extract hardware support from an object > > file and create a json string to make hardware support info discoverable > > later. > > > > Signed-off-by: Neil Horman > > Acked-by: Panu Matilainen > > CC: Bruce Richardson > > CC: Thomas Monjalon > > CC: Stephen Hemminger > > CC: Panu Matilainen > > Hi, > > I was running some crypto unit tests and I realized that the tests do not pass anymore, > because the creation of the software crypto device fails, due to this patch. > > The reason is that the name of the pmd has changed (some names have changed, > like eth_pcap to pcap, whereas others have remained the same, like eth_null), > so the name passed to rte_eal_vdev_init has to be changed. > > I am not sure if that is going to cause any problems, because users will have to > change their code because of this name change. > > Also, if now the name is being set with PMD_REGISTER_DRIVER, > then we should remove it from the rte_driver structure, right? > > static struct rte_driver pmd_ring_drv = { > .name = "eth_ring", <-- This is being overwritten by PMD_REGISTER_DRIVER? > .type = PMD_VDEV, > .init = rte_pmd_ring_devinit, > .uninit = rte_pmd_ring_devuninit, > }; > > PMD_REGISTER_DRIVER(pmd_ring_drv, eth_ring); The short answer to the question is yes, there is no real need to explicitly call out the name in the definition of the rt_driver structure definition. I made this change because some drivers failed to provide a driver name at all (which was previously acceptable), but with the introduction of this patch the name field is also used to construct the intermediate strings from which the exported information is built. We could restore the origional name of the driver that was renamed, though I'm not sure which one that is (the example you provide should result in the pmd having the exact same name). Or we could update the registration macro to use the cryptodev name macros. Neil > > Pablo > >