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

[Bruce Richardson]

On Fri, Jul 24, 2020 at 03:54:33PM +0200, Thomas Monjalon wrote:
> 24/07/2020 15:48, Parav Pandit:
> > Hi Bruce,
> > 
> > > From: Bruce Richardson <bruce.richardson at intel.com>
> > > Sent: Friday, July 24, 2020 4:37 PM
> > > 
> > > 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:
> > > 
> > I updated the commit log as you suggested below along with RB, ack tag.
> > Thank you.
> > 
> > >   Drivers dependencies are evaluated in the order defined per their parent
> > >   directory (also called class). This strict ordering prevents from us
> 
> Is "from us" too much?

The word "from" is incorrect, anyway, it should just be "prevents us".
Evidently I didn't proofread my own text well enough. :-(

> 
> > >   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.
> 
> For now it is used only to have common/mlx5 isolated of the rest
> of common drivers, as an exception.
> I think it is good to keep common/meson.build
> until there are more exceptions than the rest.
> 

+1 agreed. 
Just suggesting possible future changes depending on how things
go, and also seeding the idea that any out-of-order build processing should
really be limited to the common folder.

/Bruce