On Fri, May 20, 2016 at 10:55:26AM +0200, Thomas Monjalon wrote: > 2016-05-20 08:22, Panu Matilainen: > > Ability to query individual DSOs is a building block for other things > > like automation (you dont expect normal users to go manually loading hw > > support modules for the OS either), but its not an end-user solution. > > > > Thomas said in http://dpdk.org/ml/archives/dev/2016-May/038324.html: > > > > "This tool should not behave differently depending of how DPDK was > > compiled (static or shared)." > > I meant the basic tool must be usable on static binary and shared library. > > > Its entirely possible to handle all the three above cases virtually > > identically (point the tool to the app executable), so I have a hard > > time understanding the level of resistance to handling the plugin case. > > We need first a basic tool. Then we'll check how to build on it for > end user needs. I think you have some good ideas. > We could also try (later) to inspect a running DPDK app. >
I've thought about that, and its actually pretty easily doable. If we move the driver registration list to a shared memory segment, we could just attach to it and read it. Neil
