From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>, <dev@dpdk.org>
Subject: Re: RFC abstracting atomics
Date: Wed, 11 Jan 2023 14:18:09 +0000 [thread overview]
Message-ID: <Y77FIWp015TLGTMc@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87656@smartserver.smartshare.dk>
On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Brørup 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ørup 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.
>
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!
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.
/Bruce
next prev parent reply other threads:[~2023-01-11 14:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 22:56 Tyler Retzlaff
2023-01-10 9:16 ` Bruce Richardson
2023-01-10 11:45 ` Morten Brørup
2023-01-10 20:31 ` Tyler Retzlaff
2023-01-11 7:45 ` Morten Brørup
2023-01-10 20:10 ` Tyler Retzlaff
2023-01-11 10:10 ` Bruce Richardson
2023-01-11 10:23 ` Morten Brørup
2023-01-11 11:56 ` Bruce Richardson
2023-01-11 12:46 ` Morten Brørup
2023-01-11 14:18 ` Bruce Richardson [this message]
2023-01-11 15:07 ` Morten Brørup
2023-01-13 14:18 ` Ben Magistro
2023-01-13 16:10 ` Jerin Jacob
2023-01-13 17:17 ` Tyler Retzlaff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y77FIWp015TLGTMc@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=roretzla@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).