On Mon, 22 Jul 2019 19:31:08 +0200 Thomas Monjalon <tho...@monjalon.net> wrote:
> 22/07/2019 19:13, Stephen Hemminger: > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > Are the constructors run on dlopen of the bus driver? > > > > Yes, constructors are run on dlopen. > > But application should not have to ask DPDK to dlopen the bus devices. > > > > The core principle is that dynamic build of DPDK should act the same as old > > statically linked DPDK. Otherwise, the user experience is even worse, and > > all > > the example documentation is wrong. > > OK, this is where I wanted to bring the discussion. > You are arguing against a design which is in DPDK from some early days. > So this is an interesting discussion to have. > Do we want to change the "plugin model" we have? > Or do we want to simply drop this model (dlopen calls) > and replace it with strong dynamic linking? > > What I think should happen (and isn't is): 1. The PCI bus library is linked with --whole-archive, and --no-as-needed. This causes constructor to be called and register the bus. 2. As part of the build process all the PCI drivers pmdinfo would get constructed into a table of vendor/device to PMD shared library name. 3. PMD's are linked as --whole-archive, and --as-needed. 4. New code in PCI probe which looks for existing entries (static or -d) for devices. If device is still not found it refers to the table of PMD's (from #2) and calls dlopen for that device (and adds it to static table). This would allow examples and customer applications to Just Work without having to know the PMD that is present. It would also solve the problem that currently if applications is linked with -ldpdk linker script then all PMD's get pulled into the application address space.
