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 E98E4A052A; Mon, 25 Jan 2021 11:29:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D5B1F140EA9; Mon, 25 Jan 2021 11:29:31 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id EF1CB140E9B for ; Mon, 25 Jan 2021 11:29:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611570570; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CMxMmpzPfzok60ZRrjYS60KgLX7fupKIiPV0in6PLtk=; b=V0WAcUCb5yqzDxjggrTqqRo5cG/P9UyDGXB+J22VHR/FrJbTwXecOwy/njKrTMEIgU17SO DI0LPoifCV4tnPTgWBDQAjUIuYCSKKfBAF50WyWrQwyNzMnR3GJOUFLgz3N6FVpCI+XUIt Ul4EiYbzU2RDXoNp2Q0LMt4eNGVjO4E= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-467-nn8ndXCsN-GUdEkQMHOB8Q-1; Mon, 25 Jan 2021 05:29:28 -0500 X-MC-Unique: nn8ndXCsN-GUdEkQMHOB8Q-1 Received: by mail-ua1-f72.google.com with SMTP id x2so5033827uao.9 for ; Mon, 25 Jan 2021 02:29:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CMxMmpzPfzok60ZRrjYS60KgLX7fupKIiPV0in6PLtk=; b=cIQM4ifoToM6avLStPMDDEZj4w/bmfGtOWYaJ0UCMUpO7edlGGIkdaqJ9vBrYAdrQJ cFP7SkOuwyCg9MRovJoafhLd0Pu5D1v6GEUiOzs4MUqJDiU0MKWAkafbOpRpjc4RpOnA pA40bRkF4dnT8vk3DXh75tW53CIJAHcwBmtAHobxLRJNUpkQzMRJ2RVL7KnA6UFvlY9R MzswUAlShEAudnP5SDOU5Zw+jW7LFi8GHS52sO5+sSDYol/3fWBiZnaVMc6Oze98Ro37 eM7Wdop7a1G/9JHnIG320FIEv11TJWr1+lpdQxXVCIJbb0TQmCB2Zf+miCScLqf6KXgv /GXg== X-Gm-Message-State: AOAM533yItZzd0pvi/7TOoQ14JNJqHLzLEg9FzzwgbRh9I2VbyrqablW RhdyrYRELciQIc9FUACf5FeY2YA34FlBhxgmJanLVnSfwWA5QqFlrGqW8AETxN0oCZkV1c/2VgC sSw7lYgoJARSUZ3ONscQ= X-Received: by 2002:a67:ecd5:: with SMTP id i21mr11513vsp.18.1611570568032; Mon, 25 Jan 2021 02:29:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJxnqgW8qlA6UYiHsvZ4Nm5SNeyZpeYM6uOttYDxRKLYqEjxSz2l2B7Wqf3CPrnQhwP46LSIWx+ejAskTS2aPDQ= X-Received: by 2002:a67:ecd5:: with SMTP id i21mr11506vsp.18.1611570567773; Mon, 25 Jan 2021 02:29:27 -0800 (PST) MIME-Version: 1.0 References: <20201014183136.22239-1-dmitry.kozliuk@gmail.com> <5444857.Q0qPc8oPp2@thomas> <20210123012403.1bdb35d0@sovereign> <14261305.cmbqrkYmuW@thomas> In-Reply-To: From: David Marchand Date: Mon, 25 Jan 2021 11:29:16 +0100 Message-ID: To: "Kinsella, Ray" Cc: dev , Thomas Monjalon , Dmitry Kozlyuk Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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, Jan 25, 2021 at 11:01 AM Kinsella, Ray wrote: > > > > On 25/01/2021 09:25, 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? > > > > Ray K > > > Another point is - shouldn't _pmd_info probably live in "INTERNAL" is anycase? The symbol itself can be hidden from the ABeyes. It is only a placeholder for the PMD_INFO_STRING= string used by usertools/dpdk-pmdinfo.py and maybe some other parsing tool. I guess a static symbol would be enough: diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c index a68d1ea999..14bf7d9f42 100644 --- a/buildtools/pmdinfogen/pmdinfogen.c +++ b/buildtools/pmdinfogen/pmdinfogen.c @@ -393,7 +393,7 @@ static void output_pmd_info_string(struct elf_info *info, char *outfile) drv = info->drivers; while (drv) { - fprintf(ofd, "const char %s_pmd_info[] __attribute__((used)) = " + fprintf(ofd, "static const char %s_pmd_info[] __attribute__((used)) = " "\"PMD_INFO_STRING= {", drv->name); fprintf(ofd, "\\\"name\\\" : \\\"%s\\\", ", drv->name); We will need an exception for the v21 ABI though. -- David Marchand