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 A5969A0562; Thu, 2 Apr 2020 16:28:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 92E362BCE; Thu, 2 Apr 2020 16:28:10 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 699C42BAF for ; Thu, 2 Apr 2020 16:28:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585837687; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4PuYNPtp7K/ifapm5khX0qKVKgOCnjNjRBvYHmZ9GoM=; b=WPZCay8X6/NbeuphWdrVjCJCVk12pwMZ+8Pbq9yhrruGQ4m7nRTjyZHbWuhxLGRcNKYh// /RmnwTzAn2tvdm4++MyoPt+h64J/LYPLG6QSylEV4palsbEl6Nk0c0ic7bGNE+SoKuYKbW f+FzmMXHrXiJapbIjm8zZ9qCGCyTVOU= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-262-rQKOnkprPYmEqy71ZWGXeA-1; Thu, 02 Apr 2020 10:27:54 -0400 X-MC-Unique: rQKOnkprPYmEqy71ZWGXeA-1 Received: by mail-ua1-f71.google.com with SMTP id 59so1275110uaw.6 for ; Thu, 02 Apr 2020 07:27:54 -0700 (PDT) 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=VW+o7tQc2Oi1rHAaV50pr9pPS8gjvfNP9CHTcGIfx7o=; b=JaUd/pzdbrVfoPdDWjQIq+zgmJiI7VNb2sKk08OXgsY/2psy/F3vhO4Av3Gh+lwQYX hLI0FKACe8fJOmWG34C++Gv/Xqrn4C4XkD3c/mppP4JbEMSkehqYa+/rTyb9cP4jC355 Hfnc+x34pCvOD4yDZeepdQ2H3XdL8gTTk+f5jROgmMIld5oq2Y4rh6fGw6a7dkePS2nr GnX9dDY93FoAzM1COhEeItnJQSWMAKAEng4NG4T+UdI7qm3kFP/6svN36qcIyrfQ20BO FEcUgHXQ9pnkwKrm6LUud6Rz81Fq3CsjOlPzw5ttWMawcMbn70HFpQc86bzPa1+gZhvS dCGg== X-Gm-Message-State: AGi0PuY1C+7P1y5UHFUi6UXy5e0YnXgTxtqXqqgZ0VprLDVixzkKyu2N c5yeOcqqH8AWj4qVNhaBHFmwxo9Z7v4xpexZEdRa94YCh/ZO/L3gORIZt/R4/H0rh197/wOzFw6 xfm6oZCFkaFZ1/TE7KpQ= X-Received: by 2002:a9f:2204:: with SMTP id 4mr2684034uad.87.1585837673919; Thu, 02 Apr 2020 07:27:53 -0700 (PDT) X-Google-Smtp-Source: APiQypKiDKVGqVUJdCPlaaEz1lJAfFIV74+RhUGnmXmTehau898LWc5e0e16DCjF274x0loSU3/0abS3yw9mD9l2CVw= X-Received: by 2002:a9f:2204:: with SMTP id 4mr2683945uad.87.1585837672748; Thu, 02 Apr 2020 07:27:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Marchand Date: Thu, 2 Apr 2020 16:27:41 +0200 Message-ID: To: "Ananyev, Konstantin" , Dodji Seketeli Cc: "thomas@monjalon.net" , "nhorman@tuxdriver.com" , "honnappa.nagarahalli@arm.com" , "dev@dpdk.org" , "Richardson, Bruce" , "Yigit, Ferruh" , "Laatz, Kevin" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] /validate-abi.sh complains [PATCH v1 3/8] ring: introduce RTS ring mode 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" On Thu, Apr 2, 2020 at 2:37 PM Ananyev, Konstantin wrote: > > For the time being, you can waive this by adding a rule in > > devtools/libabigail.abignore. > > Ok, so what is the procedure here? > Should I submit changes to devtools/libabigail.abignore together with the > patch that introduced the problem? > BTW, I used the following changes in libabigail.abignore to supress error= s: > $ git diff devtools/libabigail.abignore > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index a59df8f13..032479b9f 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -11,3 +11,9 @@ > type_kind =3D enum > name =3D rte_crypto_asym_xform_type > changed_enumerators =3D RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > +; Ignore updates of ring prod/cons > +[suppress_type] > + type_kind =3D struct > + name =3D rte_ring > + has_data_members_inserted_at =3D offsetof(prod) > + has_data_members_inserted_at =3D offsetof(cons) Hum, I could not find offsetof() in the manual but I did find offset_of(). But anyway, I understand this has_data_members_inserted_at is a way to select structs. Not a way to filter out changes that touches fields offsets inside the rte_ring structure. So you might as well simplify the rule and suppress the whole rte_ring struct changes. I suspect this is what is happening here: abidiff did not complain about the offsetof vs offset_of thing, so the has_data_members_inserted_at criterias may have been ignored. --=20 David Marchand