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 88E60423AC; Wed, 11 Jan 2023 13:46:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7953140A7D; Wed, 11 Jan 2023 13:46:07 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 09E8240691 for ; Wed, 11 Jan 2023 13:46:06 +0100 (CET) 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: RFC abstracting atomics Date: Wed, 11 Jan 2023 13:46:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87656@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC abstracting atomics Thread-Index: Adkls9Co/Jbn7Oo8TcOwhY8V+qFajwAAE0HQ References: <20230109225604.GA25566@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230110201033.GC21476@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87651@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" Cc: "Tyler Retzlaff" , 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: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Wednesday, 11 January 2023 12.57 >=20 > On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Br=F8rup wrote: > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > Sent: Wednesday, 11 January 2023 11.10 > > > > > > One additional point that just became clear to me when I started > > > thinking > > > about upping our DPDK C-standard-baseline. We need to be careful > what > > > we > > > are considering when we up our C baseline. We can mandate a > specific > > > compiler minimum and C version for compiling up DPDK itself, but I > > > think we > > > should not mandate that for the end applications. > > > > Why not? > > > > And do you consider this backwards compatibility a build time or run > time requirement? > > > > > > > > That means that our header files, such as atomics, should not > require > > > C99 > > > or C11 even if the build of DPDK itself does. More specifically, > even > > > if we > > > bump DPDK minimum to C11, we should still allow apps to build = using > > > older > > > compiler settings. > > > > > > Therefore, we probably need to maintain non-C11 atomics code paths > in > > > headers beyond the point at which DPDK itself uses C11 as a code > > > baseline. > > > > Am I misunderstanding your suggestion here: Code can be C11, but all > APIs and header files must be C89? > > > > Wouldn't that also prevent DPDK inline functions from being C11? > > > Yes, it would. >=20 > Now, perhaps we don't need to ensure that our headers have strict C89 > compatibility, but I think we need to be very careful about mandating > that > end-user apps use particular c standard settings when compiling their > own > code. I get your point, Bruce, but I disagree. There should be a limit for how backwards compatible we want DPDK to be, = and the limit should certainly not be C89. It might be C99 for a while, = but it should soon be C11. If someone is stuck with a very old C compiler, and already rely on = (extended) LTS for their compiler and runtime environment, why would = they expect bleeding edge DPDK to cater for them? They can use some old = DPDK version and rely on DPDK LTS. If you want to use an old compiler, you often have to use old libraries = too, as new libraries often require newer compilers. This also applies = to the Linux kernel. I don't see why DPDK should be any different. But... DPDK LTS is only two years!?! My point is: What you are = describing is not a DPDK problem, it is a DPDK LTS policy problem.