The attached patch series largely eliminates condiitonals on
__HAVE_ATOMIC_AS_MEMBAR by introducing wrappers
membar_release_preatomic and membar_acquire_postatomic with the
obvious definitions.
I'm on the fence about it because I'm tempted to say that maybe
membar_acquire and membar_release should be defined conditionally in
the first place, and we shouldn't introduce new names:
- If you want a release before a store, or an acquire after a load,
you should use atomic_store_release or atomic_load_acquire.
membar_release and membar_acquire are already supposed to be used
only around atomic r/m/w operations as is. It's annoying to have a
proliferation of very-similar membars, a situation I was trying to
avoid when I deprecated membar_exit/enter.
- On the other hand, it's possible I made a mistake while auditing
uses of the now-deprecated membar_exit/enter and replacing them by
membar_release/acquire, and if we redefined membar_release/acquire
to be weaker, it might invite hard-to-find bugs.
Opinions welcome!
P.S. There are also still a few uses of membar_enter in critical
locking code that I don't understand and aren't clearly documented,
and a couple uses of membar_producer in subr_pcq.c that seem wrong.
If it weren't such critical central code I would just rip theese out
for being obviously bogus, but someone really needs to go through and
identify -- and very clearly document -- what purpose these serve.
>From 53d4e54d5c3926a7de096f1e04686dfd8aabaefe Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastr...@netbsd.org>
Date: Sun, 22 Jan 2023 18:45:19 +0000
Subject: [PATCH] npf(9): Another comment tweak to match upstream.
No functional change.
---
sys/net/npf/npf_tableset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/net/npf/npf_tableset.c b/sys/net/npf/npf_tableset.c
index 8f2d36c90341..c09a0919009b 100644
--- a/sys/net/npf/npf_tableset.c
+++ b/sys/net/npf/npf_tableset.c
@@ -101,7 +101,7 @@ struct npf_table {
/*
* Table ID, type and lock. The ID may change during the
- * config reload, it is protected by the npf->config_lock.
+ * config reload, it is protected by the npf_t::config_lock.
*/
int t_type;
unsigned t_id;
