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

[John W. Linville]

On Wed, Apr 16, 2014 at 06:11:32PM +0200, Olivier MATZ wrote:
> Hi Neil,
> 
> On 04/16/2014 03:08 PM, Neil Horman wrote:
> >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?
> >>
> >Because its a one line declaration inside a driver function that points to the
> >structure used to initilze the pmd?  Having to append ((__constructor__)) to
> >each initalization function is both error prone during entry and exposes the
> >possibiilty of developers doing "too much" in their constructor.  It also allows
> >for easy updating to all drivers, if additional boilerplate work needs to be
> >done in the future for all pmds.
> 
> Even if it's not critical, in my opinion, the following code is easier
> to understand:
> 
> 	__attribute__((constructor))
> 	static void
> 	rte_pmd_ring_init(void)
> 	{
> 		rte_eal_dev_driver_register(&pmd_ring_drv);
> 	}
> 
> Than:
> 
> 	PMD_REGISTER_DRIVER(pmd_ring_drv);
> 
> 
> The first version explicitly shows what you are doing: defining a
> static function called at initialization that registers a driver
> structure.
> 
> With the second, we're tempted to check what this macro does...

Which you will do once, and then forever be thankful that ever after
you will only have to read the simple macro rather than all that
nasty boilerplate and __attribute__ gorp...

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