From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id B2D0BADD2 for ; Fri, 20 May 2016 11:12:45 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C4BA7F6A2; Fri, 20 May 2016 09:12:45 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-156.ams2.redhat.com [10.36.6.156]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4K9ChYO030457; Fri, 20 May 2016 05:12:43 -0400 To: Thomas Monjalon References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <20160519120031.GC4128@hmsreliant.think-freely.org> <2679234.W5Qx41Uy7C@xps13> Cc: Neil Horman , dev@dpdk.org, Bruce Richardson , Stephen Hemminger From: Panu Matilainen Message-ID: <44d70153-ac5f-5ca0-6076-d9ebf929083d@redhat.com> Date: Fri, 20 May 2016 12:12:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2679234.W5Qx41Uy7C@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 20 May 2016 09:12:45 +0000 (UTC) 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 09:12:45 -0000 On 05/20/2016 11:55 AM, 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. Well, I'm not sure I would interpret that any differently in terms of what to expect. But since its all up to interpretation and different points of view... >> 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'll just say fair enough, I've made my points and I'll go shut up for now. - Panu -