On Tue, Apr 26, 2016 at 01:39:47PM -0400, Neil Horman wrote: > Hey- > So a few days ago we were reviewing Davids patch series to introduce the > abiilty to dump hardware support from pmd DSO's in a human readable format. > That effort encountered some problems, most notably the fact that stripping a > DSO removed the required information that the proposed tool keyed off, as well > as the need to dead reckon offsets between symbols that may not be constant > (dependent on architecture). > > I was going to start looking into the possibility of creating a modinfo > section in a simmilar fashion to what kernel modules do in linux or BSD. I > decided to propose this solution instead though, because the kernel style > solution requires a significant amount of infrastructure that I think we can > maybe avoid maintaining, if we accept some minor caviats > > To do this We emit a set of well known marker symbols for each DSO that an > external application can search for (in this case I called them > this_pmd_driver<n>, where n is a counter macro). These marker symbols are > n is a counter macro). These marker symbols are exported by PMDs for > external access. External tools can then access these symbols via the > dlopen/dlsym api (or via elfutils libraries) > > The symbols above alias the rte_driver struct for each PMD, and the external > application can then interrogate the registered driver information. > > I also add a pointer to the pci id table struct for each PMD so that we can > export hardware support. > > This approach has a few pros and cons: > > pros: > 1) Its simple, and doesn't require extra infrastructure to implement. E.g. we > don't need a new tool to extract driver information and emit the C code to > build > the binary data for the special section, nor do we need a custom linker script > to link said special section in place > > 2) Its stable. Because the marker symbols are explicitly exported, this > approach is resilient against stripping. > > cons: > 1) It creates an artifact in that PMD_REGISTER_DRIVER has to be used in one > compilation unit per DSO. As an example em and igb effectively merge two > drivers into one DSO, and the uses of PMD_REGISTER_DRIVER occur in two > separate > C files for the same single linked DSO. Because of the use of the __COUNTER__ > macro we get multiple definitions of the same marker symbols. > > I would make the argument that the downside of the above artifact isn't that > big > a deal. Traditionally in other projects a unit like a module (or DSO in our > case) only ever codifies a single driver (e.g. module_init() in the linux > kernel > is only ever used once per built module). If we have code like igb/em that > shares some core code, we should build the shared code to object files and > link > them twice, once to an em.so pmd and again to an igb.so pmd. > > But regardless, I thought I would propose this to see what you all thought of > it. > > FWIW, heres sample output of the pmdinfo tool from this series probing the > librte_pmd_ena.so module: > > [nhorman at hmsreliant dpdk]$ ./build/app/pmdinfo > ~/git/dpdk/build/lib/librte_pmd_ena.so > PMD 0 Information: > Driver Name: ena_driver > Driver Type: PCI > |====================PCI Table========================| > | VENDOR ID | DEVICE ID | SUBVENDOR ID | SUBDEVICE ID | > |-----------------------------------------------------| > | 1d0f| ec20| ffff| ffff| > | 1d0f| ec21| ffff| ffff| > |-----------------------------------------------------| > > > > Ping, thoughts here?
Neil
