[dpdk-dev] [PATCH 03/15] pmd: Add PMD_REGISTER_DRIVER macro

John W. Linville linville at tuxdriver.com
Wed Apr 16 14:59:51 CEST 2014


On Wed, Apr 16, 2014 at 01:52:49PM +0200, Thomas Monjalon wrote:
> 2014-04-15 14:05, Neil Horman:
> > Rather than have each driver have to remember to add a constructor to it to
> > make sure its gets registered properly, wrap that process up in a macro to
> > make registration a one line affair.  This also sets the stage for us to
> > make registration of vdev pmds and physical pmds a uniform process
> > 
> > Signed-off-by: Neil Horman <nhorman at tuxdriver.com>
> 
> Could you explain why having a macro is better than an explicit constructor 
> function?
> 
> > +enum rte_pmd_driver_type {
> > +	PMD_VDEV = 1
> > +};
> > +
> > +extern void rte_eal_nonpci_dev_init_register(const char *name, int
> > (*dev_initfn)(const char *, const char *)); +#define PMD_REGISTER_DRIVER(d,
> > t)\
> > +void devinitfn_ ##d(void);\
> > +void __attribute__((constructor, used)) devinitfn_ ##d(void)\
> > +{\
> > +	enum rte_pmd_driver_type _t = (t);\
> > +	switch(_t)\
> > +	{\
> > +		case PMD_VDEV:\
> > +			rte_eal_vdev_driver_register(&d);\
> > +			break;\
> > +	};\
> 
> Are you sure this switch is needed?
> You are removing it in patch 7.
> 
> If someone else think this macro is a good idea, or not, speak now :)

I don't understand your objection to it?  It makes for a nice clean
declaration, rather than error-prone cut-n-pasted boilerplate code
in every driver.  Even more benefits accrue if/when the constructors
need to be changed...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


More information about the dev mailing list