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 DEEE84237C; Wed, 11 Jan 2023 16:07:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8596340E25; Wed, 11 Jan 2023 16:07:12 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 8427940A7D for ; Wed, 11 Jan 2023 16:07:11 +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 16:07:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87659@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC abstracting atomics Thread-Index: Adklx5DokL3WCIQeTpSNTvkbImJZvAABpaaA References: <20230109225604.GA25566@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230110201033.GC21476@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87651@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87656@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 15.18 >=20 > On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Br=F8rup wrote: > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > Sent: Wednesday, 11 January 2023 12.57 > > > > > > 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. > > > > > > 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. > > >=20 > I don't see it as a compiler problem, but as a codebase one. It = doesn't > matter if your compiler supports C11 if your codebase is using legacy > features from C89 that are no longer supported by later versions. > Changing > compilers can be tricky, but updating a large legacy code-base is a > much > more challenging proposition. There is a lot of old code out there in > the > world! OK. But my same argument applies: Why would you need to use a brand new = DPDK release in your project when the rest of your code base is ancient? = In that case, you should rely on DPDK LTS. >=20 > That said, I would hope that there are few large codebases out there > that > won't compile with a C99 or C11 standard language level, and there > aren't > that many things that should cause problems. However, I don't really > know for > sure, so urge caution. >=20 > /Bruce