On Mon, 24 Oct 2016 17:38:29 +0530
Shreyansh Jain <shreyansh.jain at nxp.com> 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 at RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
