[dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro usage

[Neil Horman]

On Thu, Jul 07, 2016 at 11:00:59AM +0000, De Lara Guarch, Pablo wrote:
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, June 17, 2016 7:46 PM
> > To: dev at 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 <nhorman at tuxdriver.com>
> > Acked-by: Panu Matilainen <pmatilai at redhat.com>
> > CC: Bruce Richardson <bruce.richardson at intel.com>
> > CC: Thomas Monjalon <thomas.monjalon at 6wind.com>
> > CC: Stephen Hemminger <stephen at networkplumber.org>
> > CC: Panu Matilainen <pmatilai at redhat.com>
> 
> 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
> 
>