broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE
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@fe80.eu> AuthorDate: Tue Nov 29 12:42:05 2016 +0100 Commit: Harald Welte <laforge@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@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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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
On Fri, Dec 02, 2016 at 01:43:40PM +0100, Neels Hofmeyr wrote:
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...
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.
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (2)
-
Harald Welte -
Neels Hofmeyr