It's useless to declare the str arg as const when all the function does is
assign it to a non-const pointer.
I found one caller that wants to pass a const pointer, ranap_msg_factory.c:184.
Fixing that in a commit to osmo-iuh. All other callers pass non-const str
arguments anyway.
---
include/asn1c/asn1helpers.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asn1c/asn1helpers.h b/include/asn1c/asn1helpers.h
index d6b5e18..90e78ae 100644
--- a/include/asn1c/asn1helpers.h
+++ b/include/asn1c/asn1helpers.h
@@ -21,7 +21,7 @@ uint32_t asn1bitstr_to_u32(const BIT_STRING_t *in);
uint32_t asn1bitstr_to_u28(const BIT_STRING_t *in);
uint32_t asn1bitstr_to_u24(const BIT_STRING_t *in);
-static inline void OCTET_STRING_noalloc(OCTET_STRING_t *s, const uint8_t *str, int size)
+static inline void OCTET_STRING_noalloc(OCTET_STRING_t *s, uint8_t *str, int size)
{
s->buf = str;
s->size = size;
--
2.1.4
Hi.
How to properly use range_enc_arfcns() and range_enc_range*() from
arfcn_range_decode.h? There're not many comments around the code. From
function signature it seems like range_enc_arfcns() will put results
into w parameter but in system_information.c after that there's also
call to one of range_enc_range*().
I've tried to feed output to wireshark but it decode some unexpected
stuff. So, if I have a sequence of ints which I'd like to run through
range512 for example - ho do I get the output?
--
Max Suraev <msuraev(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi Harald,
On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
> Ever since the merge in August 2015, as far as I recall, I never saw a
> single message from any osmo-bts-trx user whether
> a) the L1SAP merge back then works for them
> b) it introduced any regressions
I suspect that there were issues since the beginning of the merge. The
issue that I saw with master was reported by Sipos Csaba back in Nov
2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
Unlike Alexander, I was never able to setup a working version with
older commits including the one specified in this post.
http://lists.osmocom.org/pipermail/openbsc/2015-September/000398.html
I guess there is something wrong with the OML setup since
trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH
channel allocation, but I am not familiar enough with those procedures
to debug more.
> While some people think I sometimes write good code, I fail to believe
> that all those intrusive changes didn't break anything for OsmoTRX
> users. Still, no feedback and no fall-out was reported.
I suspect the case was that very few users, if any, had working setups
to break or to report regressions.
> Like any larger project, particularly one with different hardware
> support, we need somebody with essential interest in that hardware to
> maintain the respective back-end. Think of device driver maintainers in
> the Linux kernel as an example.
Agreed.
> We need a sub-maintainer for osmo-bts-trx, one who
> 1) consistently follows the developments in master and checks for
> regressiosn
> 2) fixes osmo-bts-trx specific bugs like the fact that GPRS measurment
> values are not passed to the PCU, breaking rate/link adaption for
> this platform
> 3) tests interoperability with OsmoTRX and other OpenBTS transceivers
> out three
> 4) ensures that important osmo-bts-trx related patches/branches end up
> in master, ensuring that master is what people use. Telling users to
> use a branch different than master is *wrong* for anything but the
> most bleeding edge / experiemental code which is to be merged ASAP.
i
I can provide a supporting role in the above tasks on behalf of Ettus
but we do need a working starting point - that makes number 4 the most
critical item. Unfortunately, I am not able to resolve the patch
differences (I painfully tried) to make master the main user branch. I
agree that directing users to the Fairwaves branch is the wrong
approach, but right now it is the only branch for osmo-bts-trx that
works.
-TT