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 7BD51A052A; Sun, 24 Jan 2021 12:58:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09013140D3F; Sun, 24 Jan 2021 12:58:35 +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 A3540140D3A for ; Sun, 24 Jan 2021 12:58:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611489512; 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=EVzeOVwgu5yocRS2ui0E5HbYdHBrMKbwHi6xWA+JeFs=; b=AOJjSoKxf4PBbDQhB0NCTz558gUktxXvwuuO7VUMRP/oIcHxahTeSrsHkYxX85vBwG2M4x IDao+AbxD0AQGxrqvpxI/n/nw09fP8yeRWQmNK2KpMsKoWsl1uFKqiXygwtPLH/tyr6Wx8 ZEC35hZbfRiEBAI7qhCRmQDX7EHmcTE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-396-kJNjwy1oOSq-01x_Tn3fvg-1; Sun, 24 Jan 2021 06:58:28 -0500 X-MC-Unique: kJNjwy1oOSq-01x_Tn3fvg-1 Received: by mail-wr1-f69.google.com with SMTP id l13so5823701wrq.7 for ; Sun, 24 Jan 2021 03:58: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:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=EVzeOVwgu5yocRS2ui0E5HbYdHBrMKbwHi6xWA+JeFs=; b=gMquMe+zw1z0Yqf2Dcqje/bVPjsq+wNKwM4cTT6kbQMlildLbYrqEqHyu8MzU7B7/C rqDebLJHCJgHz7otnibdamKPASmmfIzIalKc4vgeDfjVkeDvgJNZ8HuTJOcDvkwFUJ0H Lx7SC2BvSJN92ke13Qs//lKQBg6wMxleewgJGvdWyl/sXaPfrnAuXlxSbEM8BKTRUdC7 5RK7uZNnBjyrik3Cff4hZWR9pvVz4ESx7cCnJ2cS1RVjUOnMPwnnF59FC1p9C91vt8Gu nSPhAPuBEV+OcJDo6iw3aKDfrYZ5QxMkFSdYGe0DHYX/iIFEopF/Duwi9bM9znyc/4pi j6ZQ== X-Gm-Message-State: AOAM532+C1y+7I23MEGWn86GjzPgkY49zH4cegJK4WCAeg4zLeHLdjkJ IOOo3ZTJZcqtMX+HAEFws2IWBh9fHVdF+k5aUCFJxmKLeLwdn3Ov/ShRSUhNPsdquY+Hr9vJGMQ s40o= X-Received: by 2002:a5d:4307:: with SMTP id h7mr12790558wrq.353.1611489507575; Sun, 24 Jan 2021 03:58:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHur9dngwQ+uEPVq2Odj3a6XkYJ/8PcHAus7efNztWJ0lXoTB6yXhB+QEUFID2gMkhhslqdA== X-Received: by 2002:a5d:4307:: with SMTP id h7mr12790543wrq.353.1611489507359; Sun, 24 Jan 2021 03:58:27 -0800 (PST) Received: from localhost (91-166-131-65.subs.proxad.net. [91.166.131.65]) by smtp.gmail.com with ESMTPSA id g7sm18808279wrx.62.2021.01.24.03.58.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Jan 2021 03:58:26 -0800 (PST) Received: by localhost (Postfix, from userid 1000) id B4FE4581CAC; Sun, 24 Jan 2021 12:58:25 +0100 (CET) From: Dodji Seketeli To: "Kinsella, Ray" Cc: Dodji Seketeli , Thomas Monjalon , 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> <86o8hhi0dg.fsf@redhat.com> <25c11a4f-0ac8-ab84-fa29-fd706e018361@ashroe.eu> X-Operating-System: Fedora 34 X-URL: http://www.redhat.com Date: Sun, 24 Jan 2021 12:58:25 +0100 In-Reply-To: <25c11a4f-0ac8-ab84-fa29-fd706e018361@ashroe.eu> (Ray Kinsella's message of "Fri, 22 Jan 2021 13:12:23 +0000") Message-ID: <871reaim1q.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (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" "Kinsella, Ray" writes: > 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. Exactly. Cheers, -- Dodji