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 4C2EDA0544; Tue, 7 Jun 2022 13:09:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2DF854021D; Tue, 7 Jun 2022 13:09:12 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 7B31E40156 for ; Tue, 7 Jun 2022 13:09:10 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A089432008FA; Tue, 7 Jun 2022 07:09:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 07 Jun 2022 07:09:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1654600148; x= 1654686548; bh=zFbvoaGeGEjVJ977jcQdTUz2ALQ/n1z61CMe+lEBp44=; b=g ayRRmQDAZms2COeKu/ihucgjgIk38CdP+3qN3bSIbflmj93NvhHkVqpxT4Xl90Y7 /IrKxe8PYPq3MD43EX2lAYgpa0bM1/h5amE1BOxggDoJ/Cxbts29fj/kSv04XJUh 0blI0Dd5VoyqugM5W6XM5D4+1QZnE/8FDgW+V+sJrzKvYS+KXyYSaH/iytph3ZQ6 HrC+nYKn60EPVZNbCgBmqJhMRvKYxaNjmOQ2NjiS8lHbujM6lWRsy4R8ZG+PJJ/h XY/Si0lI8oZsXD6l5j6wZ1QB0BwGRM04366Qw9iLts5RfJV6wlXE7NFFz7Y7nrAZ zNOEGUYk+VuOxQsSKrr0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1654600148; x= 1654686548; bh=zFbvoaGeGEjVJ977jcQdTUz2ALQ/n1z61CMe+lEBp44=; b=U 05O8PE17bsP37NAYA0uuwPdouN6VmIMCmTgHUoF8ffUKmBxLKq3AEVY+eTrY4doG cQ8Ya6vjYRJ2JWdfImjytmlg+sWr3x3Jo3Q7Y2SuJAZPJWry7HQ+uH5Ns57neCuF a1DVpi96z5Zj9Nd+wPROhqWO8dCzQk9k1qUPqWq9GnYnSheaf/Bt5estRnIJuu/e Da420J7X31t+vjaVk5ZBrHS9WRiDIRm97Fl7ehyL1R0qZLA6yvn9RUr4w2Pz43vC r1l+HEC4R1s87VQXbOlEpT645BZ4C+PBBcRC4JU35QNsmK1aduKjh4oi9HYJq7AN vM4eVy+z7OdGjAGg9mnVg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddthedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Jun 2022 07:09:06 -0400 (EDT) From: Thomas Monjalon To: Kevin Laatz Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= , Bruce Richardson , Li Zhang , matan@nvidia.com, david.marchand@redhat.com, stephen@networkplumber.org, lihuisong@huawei.com Subject: Re: [PATCH v7] eal: add bus cleanup to eal cleanup Date: Tue, 07 Jun 2022 13:09:03 +0200 Message-ID: <7465552.R56niFO833@thomas> In-Reply-To: <20220603143601.230519-1-kevin.laatz@intel.com> References: <20220419161438.1837860-1-kevin.laatz@intel.com> <20220603143601.230519-1-kevin.laatz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 03/06/2022 16:36, Kevin Laatz: > During EAL init, all buses are probed and the devices found are > initialized. On eal_cleanup(), the inverse does not happen, meaning any > allocated memory and other configuration will not be cleaned up > appropriately on exit. [...] > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -56,3 +56,12 @@ > ; Ignore libabigail false-positive in clang builds, after moving code. > [suppress_function] > name = rte_eal_remote_launch > + > +; Ignore field inserted to rte_bus, adding cleanup function > +[suppress_type] > + name = rte_bus > + has_data_member_inserted_at = end > + > +; Ignore changes to internally used structs containing rte_bus > +[suppress_type] > + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus I'm not sure we can safely consider these structs as internal. The right process is to send a deprecation notice, and then remove them from the public API. For info, Li has sent a patch for the bus cleanup which is not updating the bus code: https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/ It may be a temporary solution before the deprecation.