neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/36545?usp=email )
Change subject: formalize log subsys stripping for vty
......................................................................
formalize log subsys stripping for vty
In osmocom, we historically have a leading 'D' in all of our logging
subsystem names -- not only in the enum entry name, but also as the
string in struct log_info_cat[].
As a result of this, our logging_vty code strips away the first
character of each logging subsystem name. In the VTY, we don't enter
'dmain', but only 'main' -- the VTY strips the 'D' from "DMAIN".
The intention is to make this stripping behavior optional in a
subsequent patch.
So far the code to do that is a magic "+ 1" thrown in here and there.
Instead, introduce log_subsys_name() and use it where ever logging_vty.c
does removal of the leading 'D'.
I would have liked to keep this within logging_vty.c, but unfortunately
it needs to be public API in logging.h, because of log_parse_category()
which also strips leading D and lives in logging.c.
Change-Id: I5f81343e8c7b714a4630e64ba654e391435c4244
---
M include/osmocom/core/logging.h
M src/core/libosmocore.map
M src/core/logging.c
M src/vty/logging_vty.c
4 files changed, 42 insertions(+), 5 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/45/36545/1
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 82e686f..da90d58 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -430,6 +430,8 @@
void log_set_category_filter(struct log_target *target, int category,
int enable, int level);
+const char *log_subsys_name(const struct log_info *log_info, int cat_idx);
+
/* management of the targets */
struct log_target *log_target_create(void);
void log_target_destroy(struct log_target *target);
diff --git a/src/core/libosmocore.map b/src/core/libosmocore.map
index c5ab6e3..3bb2abd 100644
--- a/src/core/libosmocore.map
+++ b/src/core/libosmocore.map
@@ -71,6 +71,7 @@
log_parse_category;
log_parse_category_mask;
log_parse_level;
+log_subsys_name;
logp_stub;
log_reset_context;
log_set_all_filter;
diff --git a/src/core/logging.c b/src/core/logging.c
index e172124..2429a0c 100644
--- a/src/core/logging.c
+++ b/src/core/logging.c
@@ -428,6 +428,13 @@
return get_value_string(loglevel_strs, lvl);
}
+/* skip the leading 'D' in category name */
+const char *log_subsys_name(const struct log_info *log_info, int cat_idx)
+{
+ const char *name = log_info->cat[cat_idx].name;
+ return name + 1;
+}
+
/*! parse a human-readable log category into numeric form
* \param[in] category human-readable log category name
* \returns numeric category value, or -EINVAL otherwise
@@ -441,7 +448,7 @@
for (i = 0; i < osmo_log_info->num_cat; ++i) {
if (osmo_log_info->cat[i].name == NULL)
continue;
- if (!strcasecmp(osmo_log_info->cat[i].name+1, category))
+ if (!strcasecmp(log_subsys_name(osmo_log_info, i), category))
return i;
}
diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c
index 678ae68..9f38c14 100644
--- a/src/vty/logging_vty.c
+++ b/src/vty/logging_vty.c
@@ -322,8 +322,7 @@
for (i = 0; i < categories->num_cat; i++) {
if (categories->cat[i].name == NULL)
continue;
- /* skip the leading 'D' in each category name, hence '+ 1' */
- osmo_str_tolower_buf(buf, sizeof(buf), categories->cat[i].name + 1);
+ osmo_str_tolower_buf(buf, sizeof(buf), log_subsys_name(categories, i));
osmo_talloc_asprintf(tall_log_ctx, *cmd_str_p, "%s%s",
i ? "|" : "", buf);
osmo_talloc_asprintf(tall_log_ctx, *doc_str_p, "%s\n",
@@ -530,7 +529,7 @@
if (!info->cat[i].name)
continue;
vty_out(vty, " %-10s %-10s %-8s %s%s",
- info->cat[i].name+1, log_level_str(cat->loglevel),
+ log_subsys_name(info, i), log_level_str(cat->loglevel),
cat->enabled ? "Enabled" : "Disabled",
info->cat[i].description,
VTY_NEWLINE);
@@ -1095,7 +1094,7 @@
if (!osmo_log_info->cat[i].name)
continue;
- osmo_str_tolower_buf(cat_name, sizeof(cat_name), osmo_log_info->cat[i].name + 1);
+ osmo_str_tolower_buf(cat_name, sizeof(cat_name), log_subsys_name(osmo_log_info, i));
level_str = get_value_string_or_null(loglevel_strs, cat->loglevel);
if (!level_str) {
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36545?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I5f81343e8c7b714a4630e64ba654e391435c4244
Gerrit-Change-Number: 36545
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria, pespin.
Hello Jenkins Builder, fixeria,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Code-Review+1 by fixeria, Verified+1 by Jenkins Builder
Change subject: add osmo_stats_report_lock api
......................................................................
add osmo_stats_report_lock api
Allow multi-threaded access to reported stats:
- enable use of a stats mutex with osmo_stats_report_use_lock(true).
- lock/unlock externally with osmo_stats_report_lock(true/false).
Rationale:
In osmo-hnbgw, we would like to collect stats from nftables, and do so
in a separate thead. The most efficient way is to write the parsing
results from nft directly to the rate_ctr destination.
But what if the main thread reports rate counters at exactly that time?
- is writing to stats atomic on a data type level?
- do applications need stats to be "atomic" as a whole?
In osmo-hnbgw in particular, there are two counters, 'packets' and
'total_bytes'. These correspond, and it would skew statistics if we
reported them out of sync to each other.
The simplest way to ensure correctness in all cases is a mutex around
the stats reporting.
But this mutex isn't needed in most of our programs. To completely avoid
any overhead the mutex may bring, make use of it optional with a global
flag.
This use case is likely to also show up in other programs that would
like to collect and report stats from a separate thread.
Related: SYS#6773
Related: osmo-hnbgw I9dc54e6bc94c553f45adfa71ae8ad70be4afbc8f
Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d
---
M include/osmocom/core/stats.h
M src/core/libosmocore.map
M src/core/stats.c
M src/vty/stats_vty.c
4 files changed, 128 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/38/36538/2
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d
Gerrit-Change-Number: 36538
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email )
Change subject: add osmo_stats_report_lock api
......................................................................
Patch Set 1:
(2 comments)
File src/core/stats.c:
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/059126a4_431954e5
PS1, Line 794: * Calling osmo_stats_report_use_lock(true) */
unfinished comment
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/6abcec23_ce7baf8d
PS1, Line 831: pthread_mutex_t *lock = g_report_lock;
> brevity; […]
I remember now, it was a useless precaution against a changing g_report_lock. Not actually important, it hardly helps, and if the caller fails to avoid races as required by the (new) API doc, it's all mayhem anyway.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d
Gerrit-Change-Number: 36538
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 09 Apr 2024 03:21:11 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email )
Change subject: add osmo_stats_report_lock api
......................................................................
Patch Set 1:
(4 comments)
Patchset:
PS1:
> I think with this you are only sorting out one of the concurrency problems when using rate_ctr/stats […]
How the caller chooses to use this remains very specialized for an application,
the main aim is to allow a hook to mutex around the stats reporting.
The way this is used in my hnbgw patch:
The main thread simply also holds a osmo_stats_report_lock() while groups are added/removed.
Because the counter-retrieving thread acquires osmo_stats_report_lock() when updating counters, things are guarded.
File src/core/stats.c:
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/4578fe90_562cc039
PS1, Line 808: pthread_mutex_destroy(g_report_lock);
> What happens if a pthread_mutex is destroyed while used? […]
good point
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/37dcc5d3_51ee4c81
PS1, Line 819: void osmo_stats_report_lock(bool lock)
> I'd definetly have 2 APIs here, one for lock and one for unlock. […]
easier to trace: good point
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/ada84510_dddd3e86
PS1, Line 831: pthread_mutex_t *lock = g_report_lock;
> what's the point of this local variable?
brevity;
but in fact looks like leftovers from evolution of the patch, thx
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d
Gerrit-Change-Number: 36538
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 09 Apr 2024 02:28:53 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36544?usp=email )
Change subject: SIP_Emulation: Match empty port as default port 5060
......................................................................
SIP_Emulation: Match empty port as default port 5060
Change-Id: I8415571a5bdc99e8cc007bb4b57bcb73b7afd4fb
---
M library/SIP_Emulation.ttcn
1 file changed, 12 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/44/36544/1
diff --git a/library/SIP_Emulation.ttcn b/library/SIP_Emulation.ttcn
index 5c00c4d..4aef536 100644
--- a/library/SIP_Emulation.ttcn
+++ b/library/SIP_Emulation.ttcn
@@ -380,6 +380,9 @@
}
if (not ispresent(t_exp.hostPort.portField)) {
t_exp.hostPort.portField := *;
+ } else if (valueof(t_exp.hostPort.portField) == 5060) {
+ /* if the port number is 5060, it may be omitted */
+ t_exp.hostPort.portField := 5060 ifpresent;
}
if (not ispresent(t_exp.urlParameters)) {
t_exp.urlParameters := *;
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36544?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I8415571a5bdc99e8cc007bb4b57bcb73b7afd4fb
Gerrit-Change-Number: 36544
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36543?usp=email )
Change subject: SIP_Emulation: Fix SIPEM_register when several conns are active
......................................................................
SIP_Emulation: Fix SIPEM_register when several conns are active
"Dynamic test case error: Port CLIENT_PROC has more than one active
connections. Message can be sent on it only with explicit addressing.".
Change-Id: Ibf868394ce2c495a78ab943ddec278a45bf71088
---
M library/SIP_Emulation.ttcn
1 file changed, 14 insertions(+), 2 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/43/36543/1
diff --git a/library/SIP_Emulation.ttcn b/library/SIP_Emulation.ttcn
index 41e6975..5c00c4d 100644
--- a/library/SIP_Emulation.ttcn
+++ b/library/SIP_Emulation.ttcn
@@ -326,9 +326,9 @@
SIP.send(sip_resp);
}
- [] CLIENT_PROC.getcall(SIPEM_register:{?,?}) -> param(sip_to, vc_hdlr) {
+ [] CLIENT_PROC.getcall(SIPEM_register:{?,?}) -> param(sip_to, vc_hdlr) sender vc_conn {
f_create_expect(sip_to, vc_hdlr);
- CLIENT_PROC.reply(SIPEM_register:{sip_to, vc_hdlr});
+ CLIENT_PROC.reply(SIPEM_register:{sip_to, vc_hdlr}) to vc_conn;
}
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36543?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ibf868394ce2c495a78ab943ddec278a45bf71088
Gerrit-Change-Number: 36543
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange