Changes

Bump version: 1.13.0.1-6d38 → 1.13.1

Change-Id: Ic648f4165427d04b25855d7c42d3b44ba155e1ad

fix --disable-log-macros

Before 9197c1ac, the AC_ARG_ENABLE(log_macros, ...)
action was hardcoded to [log_macros="yes"], so *any*
use of the flag --enable-log-macros or --disable-log-macros
would set log_macros="yes" -> AC_DEFINE([LIBOSMOCORE_NO_LOGGING]).

The commit changed this to the standard [log_macros=$enableval], but
broke the conditional test, so
- AC_ARG_ENABLE sets $enableval to "no" for --disable-* flags
-> log_macros is now "no"
-> test fails
-> LIBOSMOCORE_NO_LOGGING is never defined...

The opposite of what it should do...

Change-Id: I809ab2f61e72428ba21061055296eb83d6d710ab

Bump version: 1.12.0.73-10f3 → 1.13.0

Change-Id: I877d255890a525a34fbf89101b3ff0bbd0989c87

logging: Support nonblocking-io for log target stderr & file, make it default

The nonblocking-io used to be the mode used until recently, where wq
only was used if the write buffer was full.
This is more performant that always waiting for poll() to write, plus
the fact that we write to system synchronously, hence seeing output
immediatelly or not losing it if program crashes.
Furthermore, It turns out using wq in multithreaded programs may cause
problems, so better switch back to using nonblocking-io by default.

Related: OS#6947
Change-Id: I46420f4b174d3a9ed01e993e2e89aea3b46c0dd7

osmo_io: Move function declaration to internal header

Change-Id: I25ffb94e00225bcdc565f56a3f0f7834df00e974

osmo_io_uring: Split global init from per-thread init

osmo_iofd_init() is expected to be called per-thread, while some code in
osmo_iofd_uring_init() was only expected to be called once.

Change-Id: Ifa5c46d7532ea49869f3cfe7268fdd082906fd10

osmo_io: Lazy-initialize during osmo_iofd_setup()

This way new threads (!=main) don't need to explicitly call
osmo_iofd_init() explicitly before using osmo_io. This is specially
useful for threads using osmo_io indirectly, eg, when logging.

The osmo_iofd_setup() API is really the only main API which requires
initialization. All other APIs requiring it come after osmo_iofd_setup()
since they use an osmo_iofd pointer.

Change-Id: Ia543c1b9d111c929cd9dbed266b6d21b74e47e4b

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31

gsm0808: fix wrong codec defaults for OFR_AMR_WB
3GPP TS 48.008 chapter 3.2.2.103 states that the configuration bits of
OFR_AMR_WB are coded as follows:
"S0, S2, S4 indicates the supported Codec Configurations. S1, S3, S5,
S6, S7 are reserved and coded with zeroes."
The current default setting of 0x3F violates this requirement. Lets set
the "forbidden" settings zu zero and keep only the allowed ones.
Change-Id: I4a481def59e9c98cfdcafc2b80c0ac7df0c14130

gsm0808: add function to convert amr gsm0408 setings to gsm0808
Add a function to convert struct gsm48_multi_rate_conf, which holds the
codec settings for AMR, to S0-S15 bit representation as defined in 3GPP
TS 48.008 3.2.2.49
Change-Id: I4e656731b16621736c7a2f4e64d9ce63b1064e98 Related: OS#3548