autoconf >=2.68 demands the body of an AC_COMPILE_IFELSE to be wrapped in
an AC_LANG_SOURCE macro, otherwise outputs annoying warnings on the
invocation of `autoreconf -i`. this patch follows that demand.
and export the underlying raw value_string arrays instead:
abis_nm_obj_class_names / abis_nm_adm_state_names.
This permits the caller to use get_string_value() as well as
get_value_string().
osmo_sock_init_ofd() is a wrapper around osmo_sock_init() which will
take care of initializing and registering a 'struct osmo_fd' for the
newly-created socket.
* use write_queue where applicable
* provide functions that work on raw FD and those with osmo_fd
* add support for multiple gsmtap instances (no global variables)
Harald reported a problem in the logging:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002896.html
Reverting 81e9636454 seems to
fix the problem. However, that workaround looks ugly.
Holger gives us another clue on what was wrong:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002905.html
While digging in the manpage, I found this:
"The functions vprintf(), vfprintf(), vsprintf(), vsnprintf()
are equivalent to the functions printf(), fprintf(), sprintf(),
snprintf(), respectively, except that they are called with a
va_list instead of a variable number of arguments. These functions
do not call the va_end macro. Consequently, the value of ap is
undefined after the call. The application should call va_end(ap)
itself afterwards."
Harald reported a problem in the logging:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002896.html
Reverting 81e9636454 seems to
fix the problem. However, that workaround looks ugly.
Holger gives us another clue on what was wrong:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002905.html
While digging in the manpage, I found this:
"The functions vprintf(), vfprintf(), vsprintf(), vsnprintf()
are equivalent to the functions printf(), fprintf(), sprintf(),
snprintf(), respectively, except that they are called with a
va_list instead of a variable number of arguments. These functions
do not call the va_end macro. Consequently, the value of ap is
undefined after the call. The application should call va_end(ap)
itself afterwards."
The plan is to collect structs and routines for application
setup and remove many copies of the boilerplate code we have
right now. This starts with routines to ignore certain signals
and the stderr init code.
Increment the age of the library because a new interface was added.
Summary of changes:
s/msg_entry/osmo_config_entry/g
s/msg_entries/osmo_config_list/g
s/msg_entry_parse/osmo_config_list_parse/g
minor glitch included in this patch while I was at it:
-#include "linuxlist.h"
+#include <osmocom/core/linuxlist.h>
This can be helpful where we send GSMTAP messages to the loopback
device (localhost, 127.0.0.1) from where the kernel would then
send ICMP reject packets as nobody is listening on that port.
This patch removes a workaround to fix some strange memory corruption
now that _output() has been completely reworked and we make use of
snprintf appropriately.
This patch reworks _output() to handle snprintf() return value
appropriately and to use one single buffer to build the logging
string, instead of four.
OpenBSC> logging level
all Global setting for all subsystems <----- this description was missing
rll A-bis Radio Link Layer (RLL)
[...]
This problem was introduced by myself in:
"vty: integration with logging framework"
04139f14b6
If the input value is '0' it should not really affect the error
since it's just an indecisive bit. We accept this either an internal
'0' (generated via puncture) or as an external '0' (generated via an
external puncturing scheme). A real received bit should never be '0',
it's always gonna be closer to 1 or the other value ...
(thanks to mad@auth.se on the ML for the idea)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Far from perfect but suits our need thus far.
The viterbi with softbit input is quite cpu-intensive. Since
most received bursts are often mostly error free, you could
use a less cpu intensive algorithm (Fano ?) and with hard bit
input. Then only switch to viterbi soft bit input if the channel
is bad enough to justify it.
Soft output is not implemented as its usefulness for the block
coding is limited.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Alexander Huemer
Harald Welte
Holger Hans Peter Freyther
Sylvain Munaut