From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id D9C49594C for ; Wed, 16 Apr 2014 19:29:49 +0200 (CEST) Received: from nat-pool-rdu-t.redhat.com ([66.187.233.202] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WaTeM-0002VZ-6X; Wed, 16 Apr 2014 13:29:48 -0400 Date: Wed, 16 Apr 2014 13:29:24 -0400 From: Neil Horman To: Olivier MATZ Message-ID: <20140416172924.GE11887@localhost.localdomain> 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> <534EABB4.9020301@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534EABB4.9020301@6wind.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 17:29:50 -0000 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 > >> > >>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... > Ok, so look it up. DPDK is open source and cscope is easy to use. A module initilization macro is a common method for doing init time binding in modular programming (the best examples are the module_init() and module_exit() macros in the linux kernel). It wraps up what you need to do to tie a modular piece of your software into the larger main component, without having to know all the boilerplate behind it. Also, if you expose the use of the constructor, then you've broken out the initalization phase to every pmd you implement, and as a result, if you ever need to add code to the initilization step, you have to add it in every pmd, instead of just updating the macro. The bottom line is, your method is 5 lines of boilerplate code thats going to have to get repeated as nauseum for every pmd that gets written giving every PMD author the opportunity to miscode the constructor, vs my one line that, if it compiles, will be correct every time. Neil