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

[Bruce Richardson]

On Wed, Jan 20, 2016 at 10:40:00AM -0500, Neil Horman wrote:
> 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
> 
Hi,

while there is interesting discussion on tools, are there any objections to
taking and merging this patchset as-is to at least do the cleanup of the
existing pci ids list? I would assume that any tools for querying the patchlist
can be done as additional work once this is applied. 

Regards,
/Bruce