From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
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)
Received: from hmsreliant.think-freely.org
 ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1b3lKL-0007gf-37; Fri, 20 May 2016 10:23:02 -0400
Date: Fri, 20 May 2016 10:22:51 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Panu Matilainen <pmatilai@redhat.com>, dev@dpdk.org,
 Bruce Richardson <bruce.richardson@intel.com>,
 Stephen Hemminger <stephen@networkplumber.org>
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
Content-Disposition: inline
In-Reply-To: <2679234.W5Qx41Uy7C@xps13>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
Subject: Re: [dpdk-dev] [PATCHv2 4/4] pmdinfo.py: Add tool to query binaries
 for hw and other support information
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Fri, 20 May 2016 14:23:05 -0000

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