From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 604F2A052A; Mon, 25 Jan 2021 11:05:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E6B7A140E33; Mon, 25 Jan 2021 11:05:20 +0100 (CET) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by mails.dpdk.org (Postfix) with ESMTP id 05742140E19 for ; Mon, 25 Jan 2021 11:05:19 +0100 (CET) Received: by mail-lj1-f182.google.com with SMTP id a25so13423698ljn.0 for ; Mon, 25 Jan 2021 02:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oyX5DylOdBEjlFIuZRMFYxo2mMce6o/yQ6YxV2dPEzg=; b=UvslibZp475ghHGsKy2PSMmrJ4/C8OoKoR3+fbBaJmT98f4/zSbXKbUw4Ct7gRnbRI 0cvtQW7GahXQB1tzgLRWlmJ0EtMNT4e/6doVyeODjMKVnTfPDjn6o5ZbMlgVtCFp+yed QHlWGB2Bk505foLo3VQiv8hn2a2BI+Mj2pU0QIEE1lZENevmBn9TXta9pYDtkApzcoh8 UTZ3DzrposU8GArEBcaQJTbIfA3IAyefWfKoIp1aHkg/Fk3MjgttrJJee9SZUUm+VMfO eHXsFNQhqCi+ukNr2CC/vGXjLo95oWljG8C2Hz+Is1Au8JRtNY4myONyaG49b9meRO85 ozxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oyX5DylOdBEjlFIuZRMFYxo2mMce6o/yQ6YxV2dPEzg=; b=bXG9uZ6MVpaWSysf9J5Vth9dw7/9xqzQbJPULFiWgj8iBQYrW3VogJrbhCjoahx4AP iIshwO/tFJ9U+Pj7dAx7INfw7nWOuc8VdPyyBtQ0zcPCxLuDXQuehILNFw8wHiq9nZhQ w/U8oPNJ+SXmIxxSMLht6hcqSzcSgI/ovvqiVRHYopwQKSrtYY4LziK++0aCrYRxQbvd xXj4gEWw909nnT0VjGOsci6nBLMSX18ltC/wbcEQBjUi6mwNKov4etypkkAXagKNiE8Q F21nYl+ZmtqUsrw3A3/ohnbLUBjZbtQIjjkug4q8okgD963gk8J1PBIJYsgzad1rxqyv gj0w== X-Gm-Message-State: AOAM533NoTmIVmwRSETJLWi8/PZsFarKoFPQTScCaNUY8CWC0aggEzDU EB+Q6KJ1YubE90Eq71/OVuA= X-Google-Smtp-Source: ABdhPJyKzcH0n12seJ7S4vw/BclU1MypdYVKv4Pfc4EFTOHja833DqcY3GsvM6jBjuq93Rtg7KRdXw== X-Received: by 2002:a2e:7803:: with SMTP id t3mr496406ljc.213.1611569119534; Mon, 25 Jan 2021 02:05:19 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id y3sm1804783lfy.73.2021.01.25.02.05.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jan 2021 02:05:18 -0800 (PST) Date: Mon, 25 Jan 2021 13:05:17 +0300 From: Dmitry Kozlyuk To: "Kinsella, Ray" Cc: Thomas Monjalon , dev@dpdk.org, Stephen Hemminger , David Marchand , Maxime Coquelin , Aaron Conole , Bruce Richardson , ferruh.yigit@intel.com, ray.kinsella@intel.com Message-ID: <20210125130517.470ae277@sovereign> In-Reply-To: References: <20201014183136.22239-1-dmitry.kozliuk@gmail.com> <5444857.Q0qPc8oPp2@thomas> <20210123012403.1bdb35d0@sovereign> <14261305.cmbqrkYmuW@thomas> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Mon, 25 Jan 2021 09:25:51 +0000, Kinsella, Ray wrote: > On 23/01/2021 11:38, Thomas Monjalon wrote: > > 22/01/2021 23:24, Dmitry Kozlyuk: > >> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote: > >>> 22/01/2021 21:31, Dmitry Kozlyuk: > >>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote: > >>>>> 20/01/2021 08:23, Dmitry Kozlyuk: > >>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote: > >>>>>>> This is now the right timeframe to introduce this change > >>>>>>> with the new Python module dependency. > >>>>>>> Unfortunately, the ABI check is returning an issue: > >>>>>>> > >>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed > >>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c > >>>>>> > >>>>>> Will investigate and fix ASAP. > >>>> > >>>> Now that I think of it: strings like this change every time new PCI IDs are > >>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage, > >>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID") > >>>> added 2020-07-08, i.e. clearly outside of ABI change window. > >>> > >>> You're right. > >>> > >>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical), > >>>> which can be worked around easily, if the above is wrong. > >>> > >>> If the new format is better, please keep it. > >>> What we need is an exception for the pmdinfo symbols > >>> in the file devtools/libabigail.abignore. > >>> You can probably use a regex for these symbols. > >> > >> This would allow real breakages to pass ABI check, abidiff doesn't analyze > >> variable content and it's not easy to compare. Maybe later a script can be > >> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of > >> 5494 relevant commits between 19.11 and 20.11, though. > >> > >> To verify there are no meaningful changes I ensured empty diff between > >> results of the following command for "main" and the branch: > >> > >> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py > > > > For now we cannot do such check as part of the ABI checker. > > And we cannot merge this patch if the ABI check fails. > > I think the only solution is to allow any change in the pmdinfo variables. > > > > So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI. > However we are going to end up carrying this rule in libabigail.ignore indefinitely. > > Would it make sense to just fix the size of _pmd_info to some reasonably large value - > say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release? I don't think so. This is a JSON *string to be parsed;* considering its size as part of application *binary* interface is wrong in the first place. As for content, checking that no PCI IDs are removed is out of scope for libabigail anyway. Technically we could fix _pmd_info size, but this still allows breaking changes to pass the check with no benefit.