Build fixed in 17a6bab150bd70954b00645c8d1f18ce3ccf8948
https://gerrit.osmocom.org/568
I pushed the commit through without peer review to fix the build, so maybe have
a look whether I need to improve something.
~Neels
On Sun, Jul 24, 2016 at 01:11:33PM +0200, Neels Hofmeyr wrote:
Just to let you know, the addition of
GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore
implicitly broke the ctrl interface tests in openbsc.
FAIL: testBtsChannelLoad (__main__.TestCtrlBSC)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./ctrl_test_runner.py", line 237, in testBtsChannelLoad
self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0
SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0')
AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0
CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0
TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0'
because this is unexpected output: "unknown 0xb,0,0"
So *any* commit submitted to openbsc will currenty fail.
I'll probably fix it shortly with a commit to openbsc...
This also directed my attention towards the pchan_load mechanics. It always
shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I
guess it makes sense in the current scheme of things, though it could make even
more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F
slot, depending on current pchan mode? Similarly for upcoming
TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan
mode... (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if
at all pchan_load tweaks would come later)
~Neels