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 8AA79A0A0A; Fri, 22 Jan 2021 14:12:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 669E2140FC4; Fri, 22 Jan 2021 14:12:33 +0100 (CET) Received: from dal1relay58.mxroute.com (dal1relay58.mxroute.com [199.181.239.58]) by mails.dpdk.org (Postfix) with ESMTP id 85DC9140FBE for ; Fri, 22 Jan 2021 14:12:32 +0100 (CET) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by dal1relay58.mxroute.com (ZoneMTA) with ESMTPSA id 1772a39800c000d98d.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 22 Jan 2021 13:12:27 +0000 X-Zone-Loop: 9d3385cefa27142ce1f532f609c5f126bed8e2347b2a X-Originating-IP: [149.28.56.236] Received: from echo.mxrouting.net (echo.mxrouting.net [116.202.222.109]) by filter004.mxroute.com (Postfix) with ESMTPS id 310793EADC; Fri, 22 Jan 2021 13:12:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rQ2A0LeSXsRMfdwJDUmGuIzpVcRfsvQe5m6ZyKVGnbQ=; b=F7EGwYulsyw+zpzE5sUzJM7JmW 9DJn12jeD6VfVX/FTJJhsGW2eP2m6cYuA3jbv1e1m3T431M5BmVgHrX+pebP+VVYOuI4VT2TBrinr fL2uqXqt6cIGR0vqV7/G9yAu6VI3Sua8ex2k4hnWnKgudaO5RYoDkbi9sscHzV4QZBAzKGmMHSQtL x1ws+A0oDdQpU3Sh0W1ChR+tzVP1PCSlsG51zFteTqdpukQAmHeFipVc31nXepNgQjzp8DmwX9R4o mRckIzNg0itG3QnM89EYzF2T861AHYypgh2aiQQNbS0dIjf5ejz9k3glgBj1bEHoHWHL1unRUdoAm 0zZ5ZhCA==; To: Dodji Seketeli , Thomas Monjalon Cc: Neil Horman , Akhil Goyal , Konstantin Ananyev , Abhinandan Gujjar , dev@dpdk.org, david.marchand@redhat.com References: <20210120142558.4120552-1-mdr@ashroe.eu> <15493004.lGub55pDpk@thomas> <86sg6uiamx.fsf@redhat.com> <2579086.B9NNOlTe4A@thomas> <86o8hhi0dg.fsf@redhat.com> From: "Kinsella, Ray" Message-ID: <25c11a4f-0ac8-ab84-fa29-fd706e018361@ashroe.eu> Date: Fri, 22 Jan 2021 13:12:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <86o8hhi0dg.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev 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 22/01/2021 13:09, Dodji Seketeli wrote: > Thomas Monjalon writes: > > [...] > >>>> Then I've added (quickly) a libabigail exception rule: >>>> >>>> [suppress_type] >>>> name = rte_cryptodev >>>> has_data_member_inserted_between = {0, 1023} >>>> >>>> Now we want to improve this rule to restrict the offsets >>>> to the padding at the end of the struct only, >>>> so we keep forbidding changes in existing fields, >>>> and forbidding additions further the current struct size. >>>> Is this new rule good? >>>> >>>> has_data_member_inserted_between = {offset_after(attached), end} >>> >>> >>> Yes, this rule should do what you think it says. >>> >>>> Do you confirm that the keyword "end" means the old reference size? >>> >>> Yes I do. >>> >>> >>>> What else do we need to check for adding a new field in a padding? >>> >>> Actually, that rule will work independantly of it there is enough >>> padding or not. It'll shut down the change report, even if the added >>> data exceeds the padding. >> >> I don't understand why. >> If "end" means the old reference size, then addition after the old size >> should be reported, isn't it? > > Yes, you are right. > > What I meant is that even if (in an hypothetical case, not yours) the > padding was so "small" that it wasn't going up to the 'end' of the > struct, that rule would have still shut down the change report. Understood - you are talking about padding between members. > > [...] > > Cheers, >