From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E77EBADE9 for ; 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 ) id 1b3lKL-0007gf-37; Fri, 20 May 2016 10:23:02 -0400 Date: Fri, 20 May 2016 10:22:51 -0400 From: Neil Horman To: Thomas Monjalon Cc: Panu Matilainen , dev@dpdk.org, Bruce Richardson , Stephen Hemminger Message-ID: <20160520142251.GC17882@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <20160519120031.GC4128@hmsreliant.think-freely.org> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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