From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id AE896594C for ; Wed, 16 Apr 2014 18:11:34 +0200 (CEST) Received: by mail-wi0-f179.google.com with SMTP id z2so1647502wiv.6 for ; Wed, 16 Apr 2014 09:11:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yI6hBJgCeQ5P+YLFHYoRIeoNZU4RlmvutcUKKTbvjeU=; b=mL43U/V+DCONWADKr0KMq/sS4bp6yL5hh8LngIVr/1RIsmWkqVuRgSjWUoKt9OjO3c HmpuXoGwrcT4TmqISMCT9MinSRU5EVerjwAX7/Xqwyp0+6GCMTxfBl/q08tLwVgzLQ5j n+IRjCSqmKC3BREpsO5DGBhgs63wmEeuYnEd0i9Rh6hFHC+c0XlUfgEtZ0wG8SThlVC2 POnT8IdTIrH4+Mp7UzoNyvAQoxcCKwyI9ImuNdR4Tr+j7Auq17XXcR7GT0Qx7DqPob6Z WRn/LA+0GoXGHfWAoCYI5wguhODD3gzIVyDZZ1R/scQU3kHzBGu2HOKAivgrpw60+hU7 FQHA== X-Gm-Message-State: ALoCoQmDfNczV99J0ZEqHFe58oKcizO/97KzQmP0pqAM4DlRCsarnV596k1/Pyt3V8Dv4UvXQFWw X-Received: by 10.194.186.140 with SMTP id fk12mr7740247wjc.47.1397664695050; Wed, 16 Apr 2014 09:11:35 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id gr2sm34953424wjc.12.2014.04.16.09.11.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 09:11:34 -0700 (PDT) Message-ID: <534EABB4.9020301@6wind.com> Date: Wed, 16 Apr 2014 18:11:32 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Neil Horman References: <1397585169-14537-1-git-send-email-nhorman@tuxdriver.com> <1397585169-14537-4-git-send-email-nhorman@tuxdriver.com> <1462763.GWB5SR3fGh@xps13> <20140416130848.GC11887@localhost.localdomain> In-Reply-To: <20140416130848.GC11887@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 03/15] pmd: Add PMD_REGISTER_DRIVER macro X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:11:35 -0000 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 >> >> 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