Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
In file included from telnet_interface.c:30:0:
osmocom/core/socket.h:25:4: warning: 'struct osmo_fd' declared inside parameter list [enabled by default]
telnet_interface.c: In function 'telnet_init_dynif':
telnet_interface.c:84:4: warning: passing argument 1 of 'osmo_sock_init_ofd' from incompatible pointer type [enabled by default]
osmocom/core/socket.h:24:5: note: expected 'struct osmo_fd *' but argument is of type 'struct osmo_fd *'
|
|
As requested by Mike Morrin <Mike.Morrin@ipaccess.com>, we introduce
GSMTAP sub-types for all the different GPRS and EGPRS coding schemes.
This is neccessary due to the fact that the RLC PDU doesn't contain any
explicit indication of the coding scheme used on the radio layer.
|
|
|
|
The previous commit introduced a new msgb_trim() but the implementation
differed from the specification.
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Note that this breaks the ABI and the low level API. But it shouldn't
break the high level API, nor the conv code definitions (because fields
default to 0, and for new fields '0' is the previous behavior)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
As it turns out, if a project uses the old name but without a declaration,
it'll causes a segfault on 64 bits platform (because of the implicit
int return type which doesn't apply since here it's a pointer).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
See kernel commit f4b477c47332367d35686bd2b808c2156b96d7c7
----
The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls
take a pointer to an RB node or RB root. They do not change the
pointed objects, so add a 'const' qualifier in order to make life
of the users of these functions easier.
Indeed, if I have my own constant pointer &const struct my_type *p,
and I call 'rb_next(&p->rb)', I get a GCC warning:
warning: passing argument 1 of ?~@~Xrb_next?~@~Y discards qualifiers from pointer target type
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
----
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Hopefully no project where using them it seems
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Some of these are not always present, especially when cross compiling
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
This patch adds RB-tree based timers which scales better than the
previous list-based implementation.
It does not require any API changes. It breaks ABI because the
osmo_timer_list structure has changed though (to avoid this in
the future, we can put internal data in some private structure).
The following table summarizes the worst-case computational complexity
of this new implementation versus the previous one:
rb-tree list-based
------- ----------
calculate next timer to expire O(1) O(n)
insertion of new timer O(log n) O(n)
deletion of timer O(log n) O(1)
timer-fired scheduler O(log n) O(3n)
The most repeated cases are:
* the calculation of the next timer to expire, that happens in every
loop of our select function.
* the timer-fired scheduler execution.
This new implementation only loses in the deletion of timer scenario,
this happens because we may need to rebalance the tree after the
removal.
So I think there is some real gain if we have some situation in which
we have to handle lots of timers.
|
|
This patch adds red black trees implementation to libosmocore.
This data structure is very useful to search for elements in
ordered sets in O(log n) instead of O(n) that lists provide.
The first client of this code will be one follow up patch that
implements rbtree-based timer scheduler.
|
|
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
There have been some changes in the wireshark source code that have
never been submitted to gsmtap.h
GSMTAP_CHANNEL_PACCH has been defined in an incompatible way in mainline
wirshark :(
|
|
From: iZsh <izsh@fail0verflow.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
fixes tiny compile error:
CC socket.lo
In file included from socket.c:13:
../include/osmocom/core/logging.h:31: error: expected declaration
specifiers or ‘...’ before ‘va_list’
make[3]: *** [socket.lo] Error 1
|
|
Sometimes we need stuff like reversing every bit in each byte (but not
the byte-order).
|
|
|
|
Use the u suffix to mark the constant as unsiged integer.
This fixes:
warning: this decimal constant is unsigned only in ISO C90
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This bug was introduced in 95f7eb288c4b8b69d61fa8d68957fb21f09e11e5 and
it caused a segfault on 'write terminal'
|
|
|
|
They are not used anywhere in our libraries, so they should be defined
by the respective applications
|
|
* All loging prefixes in libraries should be DL like DLINP
* All signals / subsystems should be called S_L_* SS_L_*
* All command nodes should be called L_*_NODE
This makes sure existinc code still compiles as expected
|
|
this ensures struct msgb is the same size as before, which will ensure
binary compatibility
|
|
This patch adds a new attribute to msgb objects. This new
attribute will store a pointer to the routing information,
in the case of the A-bis link, this will be used to store
e1inp_sign_link instead of struct gsm_bts_trx.
This deprecates msg->trx, that can be removed once all
application are ported to use msg->dst.
|
|
This adds the libosmo-abis logging subsystems to libosmocore,
it uses the new change that harald proposed based on negative
numbers for library logging subsystems.
|
|
The first range (from 0 to INT_MAX/2) of signal subsystems can be
used by client applications while the second range (from INT_MAX)
is reserved for libraries.
This is useful to support signals defined in libraries that
may be used by different client applications.
|
|
Detected by Smatch
|
|
detected by Smatch
|