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 8C5B245BFD; Mon, 28 Oct 2024 11:55:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3107A402A3; Mon, 28 Oct 2024 11:55:26 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 258CE400D7 for ; Mon, 28 Oct 2024 11:55:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730112923; 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=QIIsg/QJkdBD+dUbEH6VgJn0My0MDuEviLkAl5bxxxM=; b=hqvOYzBA8u6AhQcvVk7pEkOq+IlaOalAx/p9VgP7h9T52KLfWG4gjUzz98lCNyrbBkOqXW S8D+k+yaS03o8lHdX50qZhQSYS+ezptc6jSkXDtPfHRavZ7z1wrovG+9xnosJRnJxsVOnQ YaXoGgBXOvucXUnpSFy2Wxn2fQx2WlA= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-468-XVr_VowpNkiOL7_v1NDhJw-1; Mon, 28 Oct 2024 06:55:22 -0400 X-MC-Unique: XVr_VowpNkiOL7_v1NDhJw-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-460dd31b4c1so83491991cf.1 for ; Mon, 28 Oct 2024 03:55:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730112921; x=1730717721; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QIIsg/QJkdBD+dUbEH6VgJn0My0MDuEviLkAl5bxxxM=; b=GOQunA4e5Af3zEwxSK6cSAtikvjdOr5yYoGf4cz1e4tfzas1ndTzi8P8W/DyY2q+Hw qR6abN9f6NepIAXVTADAkbkill4zdvqHgumJv2wOuQdA+4kjogYA+4CZnrA7ljM+TXCX WGRUPgBDsOq/AKTwUqUIfVpTu4c7ghEceqqHiBaFRkI3dFymzul+6ujQa9AIrgmoUba+ AgVkU0KqrEqK+c8tjL3tb+lQmh+opBIouLXtHVSQ0KInoGripJvestkfXFTfyzmJ5PpQ oqfOvsndUfSepUEjyltehg/oW0nPoOVx+MrX7v5QyfceDzbLRoBdIuc+YFVtuQZyRxrb Q/Dw== X-Forwarded-Encrypted: i=1; AJvYcCWWDvgtx7VlCmqcpwllERywo5JfXWTGDAnHT0K4eQeu9tQfoVUD4oSD9MCvqfJh9PAXhd4=@dpdk.org X-Gm-Message-State: AOJu0Ywlzgm6VRlY4KIx2AFhJjohi30KCUGYUeINDZFAngyNKHAh1yXI VE5NFXwb47Nx5b/MSM2SKkAeA+HAXFAXDDu7pY+7N2QDWFtEatOUWF4byedzahNAdRasIqg2jv8 rmJ/pxXL9z+Ru0LtqiA7RoT6/0YxwL+13fN26vohYhPUlXdd/JEE= X-Received: by 2002:a05:622a:15d0:b0:461:5571:5cc6 with SMTP id d75a77b69052e-46155715de2mr45031921cf.46.1730112921578; Mon, 28 Oct 2024 03:55:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGl4GcKg7q7YBXk/o3YV+NGr4dYu5Ccno0kovEoqc3boGRSSjsehvIdDY3TGhZMFbPfdM68Jg== X-Received: by 2002:a05:622a:15d0:b0:461:5571:5cc6 with SMTP id d75a77b69052e-46155715de2mr45031591cf.46.1730112921217; Mon, 28 Oct 2024 03:55:21 -0700 (PDT) Received: from localhost (88-120-130-27.subs.proxad.net. [88.120.130.27]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-46132381501sm33380971cf.76.2024.10.28.03.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2024 03:55:20 -0700 (PDT) Received: by localhost (Postfix, from userid 1000) id 5A1BF5073C45; Mon, 28 Oct 2024 11:55:18 +0100 (CET) From: Dodji Seketeli To: Akhil Goyal Cc: Dodji Seketeli , Ferruh Yigit , "dev@dpdk.org" , "thomas@monjalon.net" , "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "pablo.de.lara.guarch@intel.com" , "fiona.trahe@intel.com" , "declan.doherty@intel.com" , "matan@nvidia.com" , "g.singh@nxp.com" , "fanzhang.oss@gmail.com" , "jianjay.zhou@huawei.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , "konstantin.v.ananyev@yandex.ru" , "radu.nicolau@intel.com" , "ajit.khaparde@broadcom.com" , Nagadheeraj Rottela , "mdr@ashroe.eu" Subject: Re: [EXTERNAL] Re: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs Organization: Red Hat / France References: <20240905101438.3888274-1-gakhil@marvell.com> <10591cfb-d78e-4d50-9bb5-f6d1246662b3@amd.com> <87msjkdx7x.fsf@redhat.com> X-Operating-System: AlmaLinux 9.4 X-URL: http://www.redhat.com Date: Mon, 28 Oct 2024 11:55:18 +0100 In-Reply-To: (Akhil Goyal's message of "Fri, 4 Oct 2024 17:45:23 +0000") Message-ID: <87r08033ah.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Hello, Akhil Goyal writes: [...] >> I believe that if you want to know if an enumerator value is *USED* by a >> type (which I believe is at the root of what you are alluding to), then >> you would need a static analysis tool that works at the source level. >> Or, you need a human review of the code once the binary analysis tool >> told you that that value of the enumerator changed. >> >> Why ? please let me give you an example: >> >> enum foo_enum >> { >> FOO_FIRST, >> FOO_SECOND, >> FOO_END >> }; >> >> int array[FOO_END]; >> >> Once this is compiled into binary, what libabigail is going to see by >> analyzing the binary is that 'array' is an array of 2 integers. The >> information about the size of the array being initially an enumerator >> value is lost. To detect that, you need source level analysis. >> >> But then, by reviewing the code, this is a construct that you can spot >> and allow or forbid, depending on your goals as a project. >> > In the above example if in newer library a FOO_THIRD is added. > FOO_END value will change and will cause ABI break for change in existing value. > But if we replace it with inline function to get the list_end and use it in array like below. > So if FOO_THIRD is added, we will also update foo_enum_list_end() function to return (FOO_THIRD+1) > > enum foo_enum > { > FOO_FIRST, > FOO_SECOND, > }; > static inline int foo_enum_list_end() > { > return FOO_SECOND + 1; > } > int array[foo_enum_list_end()]; > > Will this cause an ABI break if we add this array in application or in library? I think this (inline function) construct is essentially the same as just adding a FOO_END enumerator after FOO_SECOND. Using either foo_enum_list_end() or FOO_END result in having the value '2' in the application using the library to get FOO_END or foo_enum_list_end(). Newer versions of the library being linked to the application won't change that value '2', regardless of the newer values of FOO_END or foo_enum_list_end(). So, adding a FOO_THIRD right after FOO_END, induces and ABI change. This change being "breaking" (incompatible) or not, really depends on what the application expects, I would say. Sorry if that looks "vague", but this whole concept is quite blurry. For instance, if you add FOO_THIRD after FOO_SECOND in the newer version of the library and the application still gets the value '2' rather than getting the value '3', and that value is actually multiplied by "two trillions" in the application to get the value of the dividend to be payed to investors, then, then that's a very big error induced by that change. That might be considered by the application as a "breaking" ABI change and you might get a call or two from the CEO of an S&P500 company that uses the library. Other applications might consider that "off-by-one" error not being problematic at all and thus might consider it not "breaking". Note that REMOVING an enumerator however is always considered an incompatible (breaking) ABI change. Adding an enumerator however has this annoying "grey topic" (not black or white) property that I am not sure how to address at this point. Cheers, -- Dodji