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...
My 2 cents,
Olivier
