From mboxrd@z Thu Jan  1 00:00:00 1970
From: Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCHv2 4/4] pmdinfo.py: Add tool to query binaries
 for hw and other support information
Date: Fri, 20 May 2016 10:22:51 -0400
Message-ID: <20160520142251.GC17882@hmsreliant.think-freely.org>
References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com>
 <20160519120031.GC4128@hmsreliant.think-freely.org>
 <ab41bf8b-7841-e747-1504-b78a346b2f44@redhat.com>
 <2679234.W5Qx41Uy7C@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Panu Matilainen <pmatilai@redhat.com>, dev@dpdk.org,
 Bruce Richardson <bruce.richardson@intel.com>,
 Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id E77EBADE9
 for <dev@dpdk.org>; Fri, 20 May 2016 16:23:04 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <2679234.W5Qx41Uy7C@xps13>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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