2 Dec
2016
2 Dec
'16
2:29 a.m.
Heads up, the current openbsc build is broken, as verified by
https://jenkins.osmocom.org/jenkins/job/OpenBSC/
This is due to below libosmocore commit, which adds two items to enum
chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking
the static assert for gsm_network->ctype_by_chreq's size:
../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is
negative
osmo_static_assert(sizeof(ctype_by_chreq) ==
^
What this patch lacks is
* adjustment of ctype_by_chreq[] according to the new additions in
libbsc/gsm_04_08_utils.c
* same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c
* enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h.
I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items
should be, but to not get distracted from my current task, and since the values
don't seem to be used by the current master branches yet, I decided to simply
revert the libosmocore commit and leave it up to the original authors to follow
up. (No need to mention that those should be merged to libosmocore and openbsc
"at the same time" to avoid builds failing.)
Thanks and apologies for any inconvenience...
~Neels
commit c3c28528de78fd5d50c3a141c2176c0da5dd7075
Refs: 0.9.0-299-gc3c2852
Author: Alexander Couzens <lynxis(a)fe80.eu>
AuthorDate: Tue Nov 29 12:42:05 2016 +0100
Commit: Harald Welte <laforge(a)gnumonks.org>
CommitDate: Thu Dec 1 15:26:29 2016 +0000
gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE
For BSC-located pcu the BSC must understand the PDCH chan request.
Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784
---
include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h
b/include/osmocom/gsm/protocol/gsm_04_08.h
index 767aa3d..c05b62e 100644
--- a/include/osmocom/gsm/protocol/gsm_04_08.h
+++ b/include/osmocom/gsm/protocol/gsm_04_08.h
@@ -1456,6 +1456,8 @@ enum chreq_type {
CHREQ_T_PAG_R_TCH_F,
CHREQ_T_PAG_R_TCH_FH,
CHREQ_T_LMU,
+ CHREQ_T_PDCH_ONE_PHASE,
+ CHREQ_T_PDCH_TWO_PHASE,
CHREQ_T_RESERVED_SDCCH,
CHREQ_T_RESERVED_IGNORE,
};
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
2 Dec
2 Dec
10:03 a.m.
On Fri, Dec 02, 2016 at 02:29:34AM +0100, Neels Hofmeyr wrote:
Heads up, the current openbsc build is broken, as
verified by
https://jenkins.osmocom.org/jenkins/job/OpenBSC/
This is due to below libosmocore commit, which adds two items to enum
chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking
the static assert for gsm_network->ctype_by_chreq's size:
../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is
negative
osmo_static_assert(sizeof(ctype_by_chreq) ==
^
What this patch lacks is
* adjustment of ctype_by_chreq[] according to the new additions in
libbsc/gsm_04_08_utils.c
* same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c
* enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h.
there are related changes in not-yet-pushed commits in openbsc.git,
which should be pushed by the team working on this.
It's really sad that we have such a chicken-and-egg situation now, where
we will introduce a backward-incompatibility, i.e. a newer libosmocore
will be source-code incompatible with older openbsc. This is really sad
and we should avoid such situations if possible at all.
From that point of view, the static_assert is highly
questionable in
openbsc.git, because it assumes that an enum is never getting
extended
in the library :( But of course we cannot change past versions of
openbsc.git.
But please let's all try to remember this issue and not create one
again.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:43 p.m.
From that point of view, the static_assert is highly
questionable in
openbsc.git
I'm glad that we have the assert, otherwise we would be writing past the
array's end without noticing now...
IMHO the way to update the enum is to have all patches on gerrit and collect +2
on them. Once the libosmocore part is merged, the openbsc one shall follow as
soon as possible, unfortunately having to wait for the V+1 first.
We could fix one part of this in general with a kind of LAST_ENTRY enum val in
the sense of
enum vals {
VAL1,
VAL2,
LAST
};
struct s {
int arr[LAST];
};
(where 's' stands for gsm_network)
Then the gsm_network struct size would of course change implicitly, depending
on the .h file from libosmocore.
But then it's still not possible to use the newly added enum values in the
openbsc.git (to extend those other const arrays), so a two-part commit is still
needed for this particular patch. --> move the const arrays to libosmocore?
What did you have in mind?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
1:48 p.m.
On Fri, Dec 02, 2016 at 01:43:40PM +0100, Neels Hofmeyr wrote:
I would rather have code that doesn't have such assumptions in the
firstp place, without relying on the fact that an enum of a library
doesn't extend in the future.
I see the assert more as a hack around code with broken assumption.
From that
point of view, the static_assert is highly questionable in
openbsc.git
I'm glad that we have the assert, otherwise we would be writing past the
array's end without noticing now... What did you have in mind?
I don't have the time right now to study the particular code in
question, sorry. It will hav to wait for another 10 or 20 other things
on my ever growing stack of todo items :/
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3123
days inactive
3123
days old
3 comments
2 participants
participants (2)
-
Harald Welte -
Neels Hofmeyr