On 2024-03-04 17:34, Tyler Retzlaff wrote:
On Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote:
On 2024-03-02 18:05, Stephen Hemminger wrote:
On Sat, 2 Mar 2024 14:53:22 +0100
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index 449565eeae..9a368724d5 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -2,6 +2,7 @@
* Copyright(c) 2020 Arm Limited
* Copyright(c) 2010-2019 Intel Corporation
* Copyright(c) 2023 Microsoft Corporation
+ * Copyright(c) 2024 Ericsson AB
*/
Unless this is coming from another project code base, the common
practice is not to add copyright for each contributor in later versions.
Unless it's a large contribution (compared to the rest of the file)?
I guess that's why the 916c50d commit adds the Microsoft copyright notice.
+/**
+ * Test if a particular bit in a 32-bit word is set.
+ *
+ * This function does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ * A pointer to the 32-bit word to query.
+ * @param nr
+ * The index of the bit (0-31).
+ * @return
+ * Returns true if the bit is set, and false otherwise.
+ */
+static inline bool
+rte_bit_test32(const uint32_t *addr, unsigned int nr);
Is it possible to reorder these inlines to avoid having
forward declarations?
Yes, but I'm not sure it's a net gain.
A statement expression macro seems like a perfect tool for the job,
but then MSVC doesn't support statement expressions. You could also
have a macro that just generate the function body, as oppose to the
whole function.
statement expressions can be used even with MSVC when using C. but GCC
documentation discourages their use for C++. since the header is
GCC documentation discourages statement expressions *of a particular
form* from being included in headers to be consumed by C++.
They would be fine to use here, especially considering they wouldn't be
a part of the public API (i.e., only invoked from the static inline
functions in the API).
consumed by C++ in addition to C it's preferrable to avoid them.
I'll consider if I should just bite the bullet and expand all the
macros. 4x duplication.
Also, new functions should be marked __rte_experimental
for a release or two.
Yes, thanks.
