Re: [dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 22 Jul 2019 19:31:08 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 22/07/2019 19:13, Stephen Hemminger:
> > Thomas Monjalon <thomas@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.