[dpdk-dev] [PATCH v2 10/10] pci: place all uio pci device ids in a dedicated section

[Neil Horman]

On Tue, Jan 19, 2016 at 01:35:14PM -0800, Stephen Hemminger wrote:
> On Tue, 19 Jan 2016 15:56:14 -0500
> Neil Horman <nhorman at tuxdriver.com> wrote:
> 
> > On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote:
> > > On Tue, 19 Jan 2016 09:29:31 -0500
> > > Neil Horman <nhorman at redhat.com> wrote:
> > > 
> > > > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote:
> > > > > 2016-01-18 13:30, David Marchand:
> > > > > > We could do something à la modinfo, but let's keep it simple for now.
> > > > > > 
> > > > > > With this, you can extract the devices that need to be bound to uio / vfio
> > > > > > with tools like objdump :
> > > > > > 
> > > > > > $ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm10k.so
> > > > > > 
> > > > > > Contents of section rte_pci_id_uio:
> > > > > >  15760 8680a415 ffffffff 8680d015 ffffffff  ................
> > > > > >  15770 8680a515 ffffffff 00000000 00000000  ................
> > > > > 
> > > > > Yes we need a modinfo-like tool.
> > > > > Currently, the UIO/VFIO binding can be done after parsing the PCI device list.
> > > > > It is better to define the device ids locally to their drivers but it must
> > > > > be integrated with an appropriate parsing tool at the same time.
> > > > > And more importantly than any tool, the format of these ELF data must be
> > > > > properly defined, documented and extensible.
> > > > > 
> > > > > Is there someone experimented with such format definition?
> > > > > Stephen, you were asking for this change, what is your opinion?
> > > > > I remember that Neil was also interested in this change:
> > > > > 	http://dpdk.org/ml/archives/dev/2015-January/012115.html
> > > > > Panu, Christian, this change could be related to distribution packaging.
> > > > > Thanks for helping to move this change forward.
> > > > 
> > > > Yes, I would be interested in seeing this.  Is the ask here that someone do it?
> > > > As I recall from the last thread that you reference, I thought David M was
> > > > interested in writing it and soliciting for ideas.  If thats no longer the case,
> > > > I can take a stab at writing it.
> > > > 
> > > > Neil
> > > > 
> > > 
> > > If these are libraries is there a way to have a real entry point
> > > to dump PCI id's. 
> > > 
> > Sure, you could write a method that could be dlsym-ed easily enough to fetch an
> > array of pci ids, or just print stuff the console.  Not sure thats the best way,
> > but definately an option
> > Neil
> 
> It is just that reading data with objdump is a kludge likely to get broken.
> 
Not suggesting that we rely on objdump in perpituity, only that we export the
data, rather than a method to access it so that it can be reached via libelf.
Using a function to return the information has implicit issues at the moment
(specifically if you dlopen a dpdk driver, its constructor will attempt to
register it with the core libraries).  While thats not catastrophic, it means
more stuff than you expect gets loaded, which might have wierd side effects.
Adding a separate section that you could reach via libelf would be nice I think

Neil