[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