gcc3 (and some gcc4) produce code which does not fit into the
0x5000-sized RAM sections. Extend them to 0x6000 for now, so it will
build correctly again. The created binary (gcc3) has been successfully
tested on my G2.
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
This makes it possible to use GSM 850 and PCS 1900 bands, as used in the
US. The support relies on the phone hardware.
Each band (900, DCS, 850, PCS, 480 and 450) can be enabled and
disabled individually for each setting.
We also disable them by default because:
- It can operate fine out of spec
- Some phone will actually do it (like using the DCS port for PCS)
- It's verbose for nothing for most people anyway
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
* We actually support TX 850/1900 now
* We try to find the better settings for a given frequency,
no matter if it's in spec or not ...
(for e.g. TXin in DCS downlink is better done with PCS config)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Depending on the chipset and the HW, not all ports are connected
and we need to know what we can use when we have the choice ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
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."
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.
Harald Welte
Wolfram Sang
Sylvain Munaut
Alexander Huemer