dexter has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-pcu/+/34190 )
Change subject: pcuif_proto: add confirmation flag to struct gsm_pcu_if_pch
......................................................................
pcuif_proto: add confirmation flag to struct gsm_pcu_if_pch
At the moment we let OsmoBTS (or OsmoBSC) look into the MAC block we
send and in case it is an IMMEDIATE ASSIGNMENT message, a confirmation
would be sent back. Unfortunately, this method is not very practical,
lets add a flag to struct gsm_pcu_if_pch to tell the receiving end that
the MAC block contains an IMMEDIATE ASSIGNMENT message that has to be
confirmed.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: Ia202862aafc1f0cb6601574ef61eb9155de11f04
---
M include/osmocom/pcu/pcuif_proto.h
M src/bts.cpp
M src/gprs_rlcmac.c
M src/pcu_l1_if.cpp
M src/pcu_l1_if.h
5 files changed, 28 insertions(+), 5 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/90/34190/1
diff --git a/include/osmocom/pcu/pcuif_proto.h b/include/osmocom/pcu/pcuif_proto.h
index bf49b06..65a0610 100644
--- a/include/osmocom/pcu/pcuif_proto.h
+++ b/include/osmocom/pcu/pcuif_proto.h
@@ -271,6 +271,9 @@
char imsi[OSMO_IMSI_BUF_SIZE];
/* GSM mac-block (with immediate assignment message) */
uint8_t data[GSM_MACBLOCK_LEN];
+ /* Set to true in case the MAC block contains an IMMEDIATE ASSIGNMENT message,
+ * for which a confirmation is required. */
+ bool confirmed_imm_ass;
} __attribute__((packed));
struct gsm_pcu_if {
diff --git a/src/bts.cpp b/src/bts.cpp
index 497c2ce..5c483d5 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -1129,7 +1129,7 @@
if (plen >= 0) {
bts_do_rate_ctr_inc(bts, CTR_IMMEDIATE_ASSIGN_DL_TBF);
if (the_pcu->pcu_if_version >= 0x0b)
- pcu_l1if_tx_pch2(bts, immediate_assignment, plen, tbf->imsi(), tbf->tlli());
+ pcu_l1if_tx_pch2(bts, immediate_assignment, plen, true, tbf->imsi(), tbf->tlli());
else
pcu_l1if_tx_pch(bts, immediate_assignment, plen, tbf->imsi());
}
diff --git a/src/gprs_rlcmac.c b/src/gprs_rlcmac.c
index 40fdfaf..d15445e 100644
--- a/src/gprs_rlcmac.c
+++ b/src/gprs_rlcmac.c
@@ -45,7 +45,7 @@
bts_do_rate_ctr_inc(bts, CTR_PCH_REQUESTS);
if (the_pcu->pcu_if_version >= 0x0b)
- pcu_l1if_tx_pch2(bts, paging_request, plen, imsi, GSM_RESERVED_TMSI);
+ pcu_l1if_tx_pch2(bts, paging_request, plen, false, imsi, GSM_RESERVED_TMSI);
else
pcu_l1if_tx_pch(bts, paging_request, plen, imsi);
diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp
index 654063e..a38e820 100644
--- a/src/pcu_l1_if.cpp
+++ b/src/pcu_l1_if.cpp
@@ -300,7 +300,8 @@
/* Send a MAC block via the paging channel. This will (obviously) only work for MAC blocks that contain an
* IMMEDIATE ASSIGNMENT or a PAGING COMMAND message. In case the MAC block contains an IMMEDIATE ASSIGNMENT
* message, the receiving end is required to confirm when the IMMEDIATE ASSIGNMENT has been sent. */
-void pcu_l1if_tx_pch2(struct gprs_rlcmac_bts *bts, struct bitvec *block, int plen, const char *imsi, uint32_t msg_id)
+void pcu_l1if_tx_pch2(struct gprs_rlcmac_bts *bts, struct bitvec *block, int plen, bool imm_ass,
+ const char *imsi, uint32_t msg_id)
{
struct gsm_pcu_if_pch pch = { 0 };
@@ -312,6 +313,7 @@
* (TS 45.002 6.5.3, 6.5.6).
*/
+ pch.confirmed_imm_ass = imm_ass;
pch.data[0] = (plen << 2) | 0x01;
bitvec_pack(block, pch.data + 1);
diff --git a/src/pcu_l1_if.h b/src/pcu_l1_if.h
index 19ec60a..34c67ba 100644
--- a/src/pcu_l1_if.h
+++ b/src/pcu_l1_if.h
@@ -156,8 +156,8 @@
int pcu_tx_neigh_addr_res_req(struct gprs_rlcmac_bts *bts, const struct neigh_cache_entry_key *neigh_key);
void pcu_l1if_tx_pch(struct gprs_rlcmac_bts *bts, struct bitvec *block, int plen, const char *imsi);
-void pcu_l1if_tx_pch2(struct gprs_rlcmac_bts *bts, struct bitvec *block, int plen, const char *imsi, uint32_t msg_id);
-
+void pcu_l1if_tx_pch2(struct gprs_rlcmac_bts *bts, struct bitvec *block, int plen, bool imm_ass,
+ const char *imsi, uint32_t msg_id);
int pcu_rx(struct gsm_pcu_if *pcu_prim, size_t pcu_prim_length);
int pcu_l1if_open(void);
void pcu_l1if_close(void);
--
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/34190
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: Ia202862aafc1f0cb6601574ef61eb9155de11f04
Gerrit-Change-Number: 34190
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newchange
Hoernchen has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/34189 )
Change subject: configure.ac: fix libtool issue with clang and sanitizer
......................................................................
configure.ac: fix libtool issue with clang and sanitizer
[this fix already exists in most of the other repos]
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I577e7d7b07acf76e5d97dcce5da206d10f5e2aeb
---
M configure.ac
1 file changed, 34 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
Hoernchen: Looks good to me, approved
diff --git a/configure.ac b/configure.ac
index 91fb36a..c29012d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,6 +23,11 @@
AC_PROG_INSTALL
LT_INIT
+dnl patching ${archive_cmds} to affect generation of file "libtool" to fix linking with clang
+AS_CASE(["$LD"],[*clang*],
+ [AS_CASE(["${host_os}"],
+ [*linux*],[archive_cmds='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags $wl-soname $wl$soname -o $lib'])])
+
dnl check for pkg-config (explained in detail in libosmocore/configure.ac)
AC_PATH_PROG(PKG_CONFIG_INSTALLED, pkg-config, no)
if test "x$PKG_CONFIG_INSTALLED" = "xno"; then
--
To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/34189
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-gprs
Gerrit-Branch: master
Gerrit-Change-Id: I577e7d7b07acf76e5d97dcce5da206d10f5e2aeb
Gerrit-Change-Number: 34189
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: merged
Hoernchen has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/34189 )
Change subject: configure.ac: fix libtool issue with clang and sanitizer
......................................................................
configure.ac: fix libtool issue with clang and sanitizer
[this fix already exists in most of the other repos]
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I577e7d7b07acf76e5d97dcce5da206d10f5e2aeb
---
M configure.ac
1 file changed, 34 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-gprs refs/changes/89/34189/1
diff --git a/configure.ac b/configure.ac
index 91fb36a..c29012d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,6 +23,11 @@
AC_PROG_INSTALL
LT_INIT
+dnl patching ${archive_cmds} to affect generation of file "libtool" to fix linking with clang
+AS_CASE(["$LD"],[*clang*],
+ [AS_CASE(["${host_os}"],
+ [*linux*],[archive_cmds='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags $wl-soname $wl$soname -o $lib'])])
+
dnl check for pkg-config (explained in detail in libosmocore/configure.ac)
AC_PATH_PROG(PKG_CONFIG_INSTALLED, pkg-config, no)
if test "x$PKG_CONFIG_INSTALLED" = "xno"; then
--
To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/34189
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-gprs
Gerrit-Branch: master
Gerrit-Change-Id: I577e7d7b07acf76e5d97dcce5da206d10f5e2aeb
Gerrit-Change-Number: 34189
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: osmith.
daniel has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/34188 )
Change subject: debian: depend on liburing-dev for debian >= 11
......................................................................
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/34188
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: If7832baec0bddbe0bbbbfe07f77bba3deb328d5c
Gerrit-Change-Number: 34188
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Attention: osmith <osmith(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 24 Aug 2023 10:05:06 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: laforge, pespin, daniel.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/32536 )
Change subject: osmo_io: Add io_uring backend
......................................................................
Patch Set 13:
(1 comment)
Patchset:
PS10:
> > > 1 failed: […]
it was possible to do it in debian/rules and debian/control after all:
https://gerrit.osmocom.org/c/libosmocore/+/34188/1
IMHO this is the most elegant solution, then we don't need to carry the package in our repositories, and we don't need to require backports on debian 10 to be set up to install libosmocore.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/32536
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I5152129eb84b31ccc9e02bc2a5c5bdb046d331bc
Gerrit-Change-Number: 32536
Gerrit-PatchSet: 13
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: daniel <dwillmann(a)sysmocom.de>
Gerrit-CC: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 24 Aug 2023 09:54:19 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: daniel <dwillmann(a)sysmocom.de>
Gerrit-MessageType: comment