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 E72F3A00C2; Mon, 22 Aug 2022 09:24:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7A0DA410FA; Mon, 22 Aug 2022 09:24:52 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 36E5740150 for ; Mon, 22 Aug 2022 09:24:51 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH 2/3] eal: uninline rte_str_to_size Date: Mon, 22 Aug 2022 09:24:47 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8728E@smartserver.smartshare.dk> In-Reply-To: <20220821205009.1317044-3-dmitry.kozliuk@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/3] eal: uninline rte_str_to_size Thread-Index: Adi1n7BOxCPND6VASz6kWdTiyUDWBQAVzjIg References: <20220821205009.1317044-1-dmitry.kozliuk@gmail.com> <20220821205009.1317044-3-dmitry.kozliuk@gmail.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Dmitry Kozlyuk" , Cc: "Ray Kinsella" 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 > From: Dmitry Kozlyuk [mailto:dmitry.kozliuk@gmail.com] > Sent: Sunday, 21 August 2022 22.50 > To: dev@dpdk.org > Cc: Dmitry Kozlyuk; Ray Kinsella > Subject: [PATCH 2/3] eal: uninline rte_str_to_size >=20 > There is no reason for rte_str_to_size() to be inline. > Move the implementation out of . > Export it as a stable ABI because it always has been public. >=20 > Signed-off-by: Dmitry Kozlyuk Acked-by: Morten Br=F8rup > --- > Now doesn't need to #include and , > but removing them breaks some DPDK code, may break user code too. > I'm not sure what is the compatibility policy in this regard. > If such a breakage is allowed, I'd remove includes and fix DPDK code. >=20 The question I'm asking myself here is: Do we want rte_common.h to = include common headers like these, just so we don't need to include them = elsewhere? I think not. I'm in favor of the principle of keeping it clean: Remove them from = rte_common.h, and deal with the consequences. If we keep them, we will forget why they are there, and some day in the = future, someone will ask what these unused headers are doing in = .