From: Thomas Monjalon <thomas@monjalon.net>
To: Robin Jarry <robin.jarry@6wind.com>
Cc: dev@dpdk.org, Neil Horman <nhorman@tuxdriver.com>,
John McNamara <john.mcnamara@intel.com>,
stable@dpdk.org, Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] usertools: fix py3 support with pyelftools>=0.24
Date: Sun, 27 Oct 2019 21:32:39 +0100 [thread overview]
Message-ID: <4227183.zDIGceruMn@xps> (raw)
In-Reply-To: <20191015123918.10775-1-robin.jarry@6wind.com>
15/10/2019 14:39, Robin Jarry:
> Running dpdk-pmdinfo.py on Ubuntu 18.04 (bionic) with python 3 and
> pyelftools installed produces no output but no error is reported
> neither:
>
> ~$ python3 usertools/dpdk-pmdinfo.py -r build/app/testpmd
> ~$ echo $?
> 0
>
> While with python 2, it works:
>
> ~# python2 usertools/dpdk-pmdinfo.py -r build/app/testpmd
> {"pci_ids": [], "name": "dpio"}
> {"pci_ids": [], "name": "dpbp"}
> {"pci_ids": [], "name": "dpaa2_qdma"}
> .....
>
> On Ubuntu 18.04, pyelftools is version 0.24. The change log of
> pyelftools v0.24 says:
>
> - Symbol/section names are strings internally now, not bytestrings
> (this may affect API usage in Python 3) (#76).
>
> We cannot guess which version of pyelftools is actually being used. The
> elftools.__version__ symbol is not consistent with each distro's package
> version. For example, on Ubuntu 16.04 (xenial), the .deb package version
> is '0.23-2' but elftools.__version__ contains '0.25'. This is certainly
> due to partial backports.
>
> To have a more consistent behaviour of this script across all versions
> of python, add the unicode_literals future import so that literal
> strings are now always "unicode".
>
> Add 2 utility functions to force a string into bytes or bytes into an
> unicode string.
>
> Force pyelftools return values to unicode strings (will do nothing with
> recent version of pyelftools).
>
> If elffile.get_section_by_name returns None with a unicode section name,
> try with the same one encoded as bytes.
>
> Also, replace all open() calls by io.open() which behaves like the
> builtin open in python 3. The only non-binary opened file is
> /usr/share/hwdata/pci.ids which is UTF-8 encoded text. Explicitly
> specify that encoding.
>
> Link: https://github.com/eliben/pyelftools/blob/v0.24/CHANGES#L7
> Link: https://github.com/eliben/pyelftools/commit/108eaea9e75a8b5a
> Fixes: 54ca545dce4b ("make python scripts python2/3 compliant")
> Cc: John McNamara <john.mcnamara@intel.com>
> Cc: stable@dpdk.org
> Signed-off-by: Robin Jarry <robin.jarry@6wind.com>
> Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
I am really scary by all of this,
but I trust you to fix it properly.
Applied, thanks
prev parent reply other threads:[~2019-10-27 20:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190910071135.27546-1-robin.jarry@6wind.com>
2019-10-15 12:39 ` [dpdk-stable] " Robin Jarry
2019-10-27 20:32 ` Thomas Monjalon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4227183.zDIGceruMn@xps \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=nhorman@tuxdriver.com \
--cc=olivier.matz@6wind.com \
--cc=robin.jarry@6wind.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).