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 C6FC6A0A0A; Fri, 22 Jan 2021 14:11:06 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42D6D140FBE; Fri, 22 Jan 2021 14:11:06 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id BEC13140FBA for ; Fri, 22 Jan 2021 14:11:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611321064; 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=fb95eTaOZBgZVuTDvumioCjlUlU6a3xQ3cjoVgrvRqc=; b=NjgXRhsdtoif5toxt+nKo1TeCsU3Hwp6Xf/Dt3zD1doezlFAvteYxHdaGfHRazFVZY3H13 43OBHKYLzUxNfPvaBiq9PXc7OBpG/LAvb12tmQAU6TaZEJk74v/FSYRKPyxpw1kw+9X0zr i98bLM+MD9K0IUkGlneD5WMeCmFC2mI= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-340-imMTuzfLMbuf3X7lWM1F-g-1; Fri, 22 Jan 2021 08:11:00 -0500 X-MC-Unique: imMTuzfLMbuf3X7lWM1F-g-1 Received: by mail-wr1-f72.google.com with SMTP id e12so3104446wrx.14 for ; Fri, 22 Jan 2021 05:11:00 -0800 (PST) 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:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=fb95eTaOZBgZVuTDvumioCjlUlU6a3xQ3cjoVgrvRqc=; b=qk8oevzunUpp+xWDo+H6Mb4BNQdl4llEDS+Q5h20od6BR9LIKfk1al+1ublBbsvH5D 4WYRi3ZnFqAap+SlqiuAxtFSDY1AoLfiLGxxWrNGjL3yjn7+iy1z0x6AKGEBJp4hu0NW jnRrGT4M4l3LqcxtnaTR2m47TQdfHyAAhiNvEP/jgriBKrRj4d3FrJ9JBcXVyqPwv2TB s53gjcIE3J8UhjXiyLJAN7hCIVkAY+wMU9SgCoPB165n3ClIiT8xrcBm+G+30U/n7Ds0 RkaX+hwRJKuXiOdPdeHHiHbLSPWJqdICh+SQlfWavc1OdxFsQOgfidar1bzQu+uWMSSP bsng== X-Gm-Message-State: AOAM5301pug5NXaRRgi7CF7Th94XedHrgXvGiJx68aEBT1czu/eKIiqz CmeeGnrGQx2CISQqepNwma9VfKoSOj+84OpXJkw4AFzDTCNhv4/wsGYZ5Wx4TJshKsyaUsi5unM 6ot8= X-Received: by 2002:adf:dd83:: with SMTP id x3mr1573713wrl.421.1611321059193; Fri, 22 Jan 2021 05:10:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJxP3z09OUKMAgBtwfqYd6cfs+3RFV2DlzZ2E7dn+O4ZlOnLkLa/EvDWSfZgO5W7XO16cVELQg== X-Received: by 2002:adf:dd83:: with SMTP id x3mr1573695wrl.421.1611321058965; Fri, 22 Jan 2021 05:10:58 -0800 (PST) Received: from localhost (91-166-131-65.subs.proxad.net. [91.166.131.65]) by smtp.gmail.com with ESMTPSA id d2sm12141455wre.39.2021.01.22.05.10.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 05:10:30 -0800 (PST) Received: by localhost (Postfix, from userid 1001) id 20C3E1A0FB8; Fri, 22 Jan 2021 14:09:47 +0100 (CET) From: Dodji Seketeli To: Thomas Monjalon Cc: Ray Kinsella , Neil Horman , Akhil Goyal , Konstantin Ananyev , Abhinandan Gujjar , dev@dpdk.org, david.marchand@redhat.com Organization: Red Hat / France References: <20210120142558.4120552-1-mdr@ashroe.eu> <15493004.lGub55pDpk@thomas> <86sg6uiamx.fsf@redhat.com> <2579086.B9NNOlTe4A@thomas> X-Operating-System: Red Hat Enterprise Linux Server 7.8 X-URL: http://www.redhat.com Date: Fri, 22 Jan 2021 14:09:47 +0100 In-Reply-To: <2579086.B9NNOlTe4A@thomas> (Thomas Monjalon's message of "Thu, 21 Jan 2021 16:58:04 +0100") Message-ID: <86o8hhi0dg.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dodji@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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" 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. [...] Cheers, -- Dodji