From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4CE28A0350; Mon, 22 Jun 2020 02:45:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8079A1C0C6; Mon, 22 Jun 2020 02:45:22 +0200 (CEST) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by dpdk.org (Postfix) with ESMTP id A9E0C1C07B for ; Mon, 22 Jun 2020 02:45:21 +0200 (CEST) Received: by mail-lf1-f68.google.com with SMTP id t74so8610435lff.2 for ; Sun, 21 Jun 2020 17:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=dzo1lnkFjqyXDyJCC4T3L8PSX68DevTYb2ohQnm+8h0=; b=AjAdDL80JRfddkyVIt3Z1586hWkb1sl1IC4donKCHjo1kHiV+VypkbWQT0Z2rSCfcE 1BHXfL1plT6LBAyE5OI68V4SL7MxdXbWrLEmuy+wNVHKhJC7opqGqw4DtGpfQX9kAgJ7 aLY1Q30KBm6qyl9eFD5byXs75j6daaDDAb10JHIOcYgjYTfXIE8iOqY7vn6G8VbHxOmo /sk4F+fKBAd3hm94xbMBfxiOeYX+fJ3ddyiZp8WHZcvXVVLC1Ixf+CasVWNpdKUfSvkr QC+z4Ene4ujrW3Fir0SlSNpHXZcLDXOqZpnsCA1AfUygAhkEg/il10kjyvQcLp2NgMn1 UIHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=dzo1lnkFjqyXDyJCC4T3L8PSX68DevTYb2ohQnm+8h0=; b=XvhrE+AClHbZXxvM+fkgLZrdzfMdnjkPm+WT+LR0MesOBL+wSUMjlzc1D2sAsuJkMO BV85dBpkXITLkLHAms6E9I876n1oygv90dr/JwRFAMMn6YOUj7X9e0blctdjnUN7sTo+ dCGam7N3Mbak3YniYvI3cLkQn34ezry8vEurbfThZ/dVDS0crkmGwrAtnRUDl7Y9FROK W6RB+vvYrzAoQzppThgU7SQxxEt40OXaLRRp69bmaX697ZEAfGGKfea12Zla1QnBEtF8 FPFr0DnRrPrm7Bl6garTHDiQX8HoNSQyjsEQvqFcQ06+sr8U3rheW3L6du59yFKDLMRW 27uw== X-Gm-Message-State: AOAM533AtpIDUc97802o6dP22/9jMNcy8ZtrbJI78B5HCHj2ve2uEY7Z actgBZpY4IDUmW5jGWgFxowYfUzq0Ug= X-Google-Smtp-Source: ABdhPJxdJCAM7bgF7vkz0ITpr5+4VCE6AsX/H+3m7VZc4AqdSDv7HCaGASy9ONUF5DRC4q3Z0ccZ3g== X-Received: by 2002:ac2:4241:: with SMTP id m1mr6979304lfl.20.1592786720627; Sun, 21 Jun 2020 17:45:20 -0700 (PDT) Received: from localhost.localdomain (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id q11sm3067009lfe.34.2020.06.21.17.45.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2020 17:45:19 -0700 (PDT) From: Dmitry Kozlyuk To: dev@dpdk.org Cc: Neil Horman , Bruce Richardson , Thomas Monjalon , robin.jarry@6wind.com, Dmitry Kozlyuk Date: Mon, 22 Jun 2020 03:45:01 +0300 Message-Id: <20200622004503.29036-1-dmitry.kozliuk@gmail.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [RFC PATCH 0/2] pmdinfogen: rewrite in Python X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" This is a PoC rewrite of pmdinfogen in Python with missing bits described below and in commits. Community input is desired. Pros: 1. Simpler build process without host apps. 2. Less build requirements (host libelf). 3. Easier debugging and maintenance with a high-level language. 4. Easier porting on Windows (only add new object format). Cons: 1. No standard ELF or COFF module for Python (amount of Python code without libelf on par with C code using it). 2. struct rte_pci_id must be synchronized with header file (it's a few lines that never change). There are no built-in or widely used Python libraries for ELF or COFF. Some ELF-parsing libraries exist on PyPI, but they're not very handy for the task and their installation would complicate build requirements. Thus, elf.py implements its own parsing. COFF support is underway, it's just not included in this RFC. Amount of code is similar to elf.py. Build is only tested on Linux x64_64. If the community deems this RFC worth finishing, there are a few opens: 1. Support for >65K section headers seems present in current pmdinfogen. However, the data it reads is not used after. Is it really needed? 2. How much error-handling is required? This is a build-time tool, and Python gives nice stacktraces. However, segfaults are possible in Python version due to pointer handling. IMO, error checking must be just sufficient to prevent silent segfaults. 3. On Unix, pmdinfogen is called for each object file extracted with ar from an .a library by a shell script. On Windows, other tools have to be used, shell script will not work. On the other hand, COFF library format is quite simple. Would it be appropriate for pmdinfogen to handle it to avoid intermediate script? --- Dmitry Kozlyuk (2): pmdinfogen: prototype in Python build: use Python pmdinfogen buildtools/elf.py | 194 +++++++++++++++++++++++++++++++++++++++ buildtools/meson.build | 3 +- buildtools/pmdinfogen.py | 144 +++++++++++++++++++++++++++++ drivers/meson.build | 2 +- 4 files changed, 340 insertions(+), 3 deletions(-) create mode 100644 buildtools/elf.py create mode 100755 buildtools/pmdinfogen.py -- 2.25.4