On Fri, Jan 06, 2023 at 10:47:06AM -0800, Tyler Retzlaff wrote: > On Fri, Jan 06, 2023 at 11:48:17AM +0000, Bruce Richardson wrote: > > On Thu, Jan 05, 2023 at 04:32:40PM -0800, Stephen Hemminger wrote: > > > On Thu, 5 Jan 2023 09:21:18 -0800 > > > Tyler Retzlaff <roret...@linux.microsoft.com> wrote: > > > > > > > On Thu, Jan 05, 2023 at 10:01:31AM +0100, Thomas Monjalon wrote: > > > > > 05/01/2023 08:09, Morten Brørup: > > > > > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > > > > > +/** > > > > > > > + * @warning > > > > > > > + * @b EXPERIMENTAL: this API may change, or be removed, without > > > > > > > prior > > > > > > > notice > > > > > > > + * > > > > > > > + * Get the count of leading 0-bits in v. > > > > > > > + * > > > > > > > + * @param v > > > > > > > + * The value. > > > > > > > + * @return > > > > > > > + * The count of leading zero bits. > > > > > > > + */ > > > > > > > +__rte_experimental > > > > > > > +static inline unsigned int > > > > > > > +rte_clzl(unsigned long v) > > > > > > > > > > > > Don't use l (long) and ll (long long) for names (and types), use > > > > > > explicit bit lengths, 32 and 64. > > > > > > > > > > > > E.g.: rte_clz32(uint32_t v) > > > > > > > > > > I agree on using numbers. > > > > > > > > > > > > > love the idea, fewer functions too. > > > > > > > > though it is a shame we cannot adopt C11 standard because we could just > > > > do away with the bit suffixes entirely. > > > > > > We could but the project needs to support older RHEL releases > > > which have older tool sets. Though probably this is moot point given > > > how much meson seems to change. > > > > True, though meson tends to be a bit easier to update than GCC on a system > > - no "pip3 install --upgrade gcc", sadly :-) > > * on linux. :) > > > > > If we can't go all the way to C11 support, how about at least going to C99 > > support? As far as I know DPDK has never updated its minimum C-standard > > version, and it might be a good idea to start the process of doing so, even > > if it is a baby step. > > the thing that blurs the line a bit is how the gcc version that is > holding us back does actually allow the use of some C99 optional > features. for example we use the C99 fixed width integer types so > technically some of the code already requires C99. > > i also notice at least one driver is explicitly specifying -std=gnu99 so > maybe that driver just isn't being built when the old gcc is detected? > > anyway, i think we are stuck pre-c99 so long as we have RHEL 7 to > contend with. the rationale is if we could use a compiler conforming to > the new standard we could just directly use those features, but so long > as we have to support non conforming compiler at a particular level we > have to introduce an abstraction and that is where all the extra work > comes from. >
AFAIK the gcc 4.8 compiler on RHEL 7/Centos 7 does support C99, it's just missing full support for C11 (which comes in 4.9). Therefore I see using C99 as hopefully being unproblematic, and allowing us to try moving forward revision and seeing what issues - if any - we hit. It should also allow us to put in place infrastructure to support such version changes, since, for example, we likely need to ensure that our headers still work with C90 compilation. /Bruce
