From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (w-smtp-out-3.wedos.net [46.28.105.99]) by dpdk.org (Postfix) with ESMTP id CBB7A2A66 for ; Mon, 24 Oct 2016 18:14:18 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3t2hDp3gVfz5qG; Mon, 24 Oct 2016 18:14:18 +0200 (CEST) Date: Mon, 24 Oct 2016 18:11:51 +0200 From: Jan Viktorin To: Shreyansh Jain Cc: "dev@dpdk.org" , "thomas.monjalon@6wind.com" , "david.marchand@6wind.com" Message-ID: <20161024181151.60ea75e7@pcviktorin.fit.vutbr.cz> In-Reply-To: <78be76eb-2ce5-59be-5a74-fd7670364710@nxp.com> References: <1473410639-10367-1-git-send-email-shreyansh.jain@nxp.com> <1476539108-13170-1-git-send-email-shreyansh.jain@nxp.com> <1476539108-13170-12-git-send-email-shreyansh.jain@nxp.com> <20161016025658.5182b5b9@jvn> <78be76eb-2ce5-59be-5a74-fd7670364710@nxp.com> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 11/17] eal/soc: add default scan for Soc devices 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: Mon, 24 Oct 2016 16:14:18 -0000 On Mon, 24 Oct 2016 17:38:29 +0530 Shreyansh Jain wrote: > Hi Jan, > > On Sunday 16 October 2016 12:42 PM, Shreyansh Jain wrote: > > Hi Jan, > > [...] > >> > >>> + > >>> +int > >>> +rte_eal_soc_scan(void) > >> > >> What about naming it rte_eal_soc_scan_default? This would underline the > >> fact that this function can be replaced. > > > > Yes, that would be in sync with match default. I will do it. > > In v5 I have replaced the name with rte_eal_soc_platform_bus(). This is > long but it does exactly what the name states - scan for platform bus. > This is still a helper. OK. > > > > >> > >> Second, this is for the 7/17 patch: > >> > >> -/* register a driver */ > >> void > >> rte_eal_soc_register(struct rte_soc_driver *driver) > >> { > >> + /* For a valid soc driver, match and scan function > >> + * should be provided. > >> + */ > >> + RTE_VERIFY(driver != NULL); > >> + RTE_VERIFY(driver->match_fn != NULL); > >> + RTE_VERIFY(driver->scan_fn != NULL); > >> > >> What about setting the match_fn and scan_fn to default implementations if > >> they > >> are NULL? This would make the standard/default approach easier to use. > >> > >> TAILQ_INSERT_TAIL(&soc_driver_list, driver, next); > >> } > > > > I am not in favor of a forced default. What if user never intended it - it would lead to wrong scan being used and only intimation which can provided to user is a log. > > Selecting such functions should be a model of PMD - one which is enforced. > > As mentioned before, I am not in favor of a 'default' implementation. > Thus, I would rather call these functions as 'helpers' rather than defaults. Hmm, OK. Jan > > [...] > > - > Shreyansh -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic