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 343A4A251 for ; Wed, 18 May 2016 13:48:35 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 826E57F6B4; Wed, 18 May 2016 11:48:33 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-221.ams2.redhat.com [10.36.5.221]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4IBmVxC026307; Wed, 18 May 2016 07:48:31 -0400 To: Neil Horman , dev@dpdk.org References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1463431287-4551-5-git-send-email-nhorman@tuxdriver.com> Cc: Bruce Richardson , Thomas Monjalon , Stephen Hemminger From: Panu Matilainen Message-ID: <3ee4159d-fd29-1a20-1417-4c0a40c18779@redhat.com> Date: Wed, 18 May 2016 14:48:30 +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: <1463431287-4551-5-git-send-email-nhorman@tuxdriver.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 18 May 2016 11:48:34 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 4/4] pmd_hw_support.py: Add tool to query binaries for hw 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: Wed, 18 May 2016 11:48:35 -0000 On 05/16/2016 11:41 PM, Neil Horman wrote: > This tool searches for the primer sting PMD_DRIVER_INFO= in any ELF binary, > and, if found parses the remainder of the string as a json encoded string, > outputting the results in either a human readable or raw, script parseable > format > > Signed-off-by: Neil Horman > CC: Bruce Richardson > CC: Thomas Monjalon > CC: Stephen Hemminger > CC: Panu Matilainen > --- > tools/pmd_hw_support.py | 174 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 174 insertions(+) > create mode 100755 tools/pmd_hw_support.py > > diff --git a/tools/pmd_hw_support.py b/tools/pmd_hw_support.py > new file mode 100755 > index 0000000..0669aca > --- /dev/null > +++ b/tools/pmd_hw_support.py > @@ -0,0 +1,174 @@ > +#!/usr/bin/python3 I think this should use /usr/bin/python to be consistent with the other python scripts, and like the others work with python 2 and 3. I only tested it with python2 after changing this and it seemed to work fine so the compatibility side should be fine as-is. On the whole, AFAICT the patch series does what it promises, and works for both static and shared linkage. Using JSON formatted strings in an ELF section is a sound working technical solution for the storage of the data. But the difference between the two cases makes me wonder about this all... For static library build, you'd query the application executable, eg testpmd, to get the data out. For a shared library build, that method gives absolutely nothing because the data is scattered around in individual libraries which might be just about wherever, and you need to somehow discover the location + correct library files to be able to query that. For the shared case, perhaps the script could be taught to walk files in CONFIG_RTE_EAL_PMD_PATH to give in-the-ballpark correct/identical results when querying the executable as with static builds. If identical operation between static and shared versions is a requirement (without running the app in question) then query through the executable itself is practically the only option. Unless some kind of (auto-generated) external config file system ala kernel depmod / modules.dep etc is brought into the picture. For shared library configurations, having the data in the individual pmds is valuable as one could for example have rpm autogenerate provides from the data to ease/automate installation (in case of split packaging and/or 3rd party drivers). And no doubt other interesting possibilities. With static builds that kind of thing is not possible. Calling up on the list of requirements from http://dpdk.org/ml/archives/dev/2016-May/038324.html, I see a pile of technical requirements but perhaps we should stop for a moment to think about the use-cases first? To name some from the top of my head: - user wants to know whether the hardware on the system is supported - user wants to know which package(s) need to be installed to support the system hardware - user wants to list all supported hardware before going shopping - [what else?] ...and then think how these things would look like from the user perspective, in the light of the two quite dramatically differing cases of static vs shared linkage. P.S. Sorry for being late to this party, I'm having some health issues so my level of participation is a bit on-and-off at the moment. - Panu -