[dpdk-dev] [PATCH v8 03/10] drivers: relax dependency order

Bruce Richardson bruce.richardson at intel.com
Fri Jul 24 13:07:18 CEST 2020


On Thu, Jul 23, 2020 at 11:09:03PM +0300, Parav Pandit wrote:
> From: Thomas Monjalon <thomas at monjalon.net>
> 
> Drivers dependencies are evaluated in the order defined per
> their parent directory (also called class).
> This strict ordering prevent from having 2 different drivers
> of the same class with different dependencies ordering.
> This problem occurs if drivers/common/mlx5 depends on drivers/bus/pci,
> while drivers/bus/dpaa depends on drivers/common/dpaax.
> Having a strict ordering between directories bus and common
> is too much restrictive.
> 
> That's why it is made possible to have a more fine-grain directory list,
> adding a driver sub-directory in the list.
> In this case, the isolated driver must be removed from its class list,
> and added directly in drivers/meson.build.
> Also, the per-class variables must be duplicated in the isolated driver,
> because the call "subdir(class)" is skipped in the isolated driver case.
> 
> Signed-off-by: Thomas Monjalon <thomas at monjalon.net>

The commit log above has some strange word-wrapping, and occasionally
strange phrasing. I think it could be slightly reworded, perhaps as:

  Drivers dependencies are evaluated in the order defined per their parent
  directory (also called class). This strict ordering prevents from us
  from having pairs of drivers from two classes with different dependency
  ordering. For example, if the mlx5 common code depends on the pci bus
  driver, while the dpaax common code is itself a dependency of the dpaa
  bus driver.  Having a strict ordering between directories bus and common
  is too restrictive, as processing either common drivers or bus drivers
  first leads us to missing dependencies in this scenario.
   
  This patch makes it possible to have a more fine-grain directory list,
  adding a specific driver sub-directory in the top-level drivers
  subdirectory list. In this case, the isolated driver must also be removed
  from its class list, and the per-class variables must be duplicated in
  the isolated driver, because the call "subdir(class)" is skipped in the
  isolated driver case.
  

Apart from that, I think this is a good idea to give us some flexibility
in managing driver ordering which should help other drivers too -
perhaps QAT? Ideally, though, I'd like if we can limit the flexible
ordering to *only* common code, in which case we could move the
per-class variables for common to the top-level to prevent duplication,
and maybe even get rid of common/meson.build completely. That, however,
will depend on how much this feature gets used and by whom.

Therefore:
Review-by: Bruce Richardson <bruce.richardson at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>



More information about the dev mailing list