Attention is currently required from: laforge, neels, pespin. Timur Davydov has posted comments on this change by Timur Davydov. ( https://gerrit.osmocom.org/c/libosmocore/+/41813?usp=email )
Change subject: Add Emscripten build support and JS callback logging backend ...................................................................... Patch Set 8: (8 comments) Commit Message: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/5d2b7efb_e11fd840?usp=email : PS5, Line 7: Add Emscripten build support and JS callback logging backend > Also, please explain whether you envision to be sending more patches related > to this topic (which ne […] Thank you for asking for additional context. The main goal is to enable partial execution of Osmocom components in isolated environments, specifically in WebAssembly runtimes, where direct access to hardware and traditional operating system facilities is not available. One of the intended use cases is running a GSM 2G base station where access to the radio part (SDR) is provided through a web environment (via WebUSB), while the remaining parts of the Osmocom stack and the core network components continue to run on a conventional backend server. In practice, the web environment would run highly stripped-down versions of `osmo-bts` + `osmo-trx` as static WASM libraries, which in turn depend on libraries such as `libosmocore`, `libosmo-netif`, and `libosmo-abis`. One practical advantage of this approach is that no deployment is required on the radio side: no local installation, configuration, or privileged access is needed on the host system. This allows a radio endpoint to be started with minimal setup, while all stateful and operational complexity remains centralized on the backend. In this model, multiple such radio endpoints can connect to the same backend core network, effectively forming a single logical network. From the perspective of the core network, these endpoints behave like remotely located base station instances, allowing subscribers registered in the same backend to communicate with each other (including voice calls and SMS), regardless of the physical location of the individual radio endpoints. Regarding future work: yes, I plan to introduce additional changes in this area gradually and on a per-component basis, following the same approach where all modifications remain isolated, optional, and inactive for native builds. Each change will be proposed independently. It is expected that this effort may eventually involve the following Osmocom projects: `libosmocore`, `libosmo-netif`, `libosmo-abis`, `osmo-bts`, and `osmo-trx`. Since `libosmocore` is a foundational dependency for these projects, some minor changes there may be required as part of this work. One of the key limitations of web environments is the lack of native support for TCP and UDP sockets. Under this approach, transport mechanisms that normally rely on TCP/UDP are adapted to use WebSocket when running in a browser. On the backend side, a gateway is planned to translate between WebSocket connections and traditional TCP/UDP sockets, allowing existing backend components such as `osmo-stp`, `osmo-hlr`, `osmo-mgw`, and `osmo-bsc` to operate unchanged. File src/core/Makefile.am: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/76614827_6d90b154?usp=email : PS7, Line 49: logging_emscripten.c \ > You need to add it conditionally based on the autoconf variable. Thanks for the suggestion, agreed. I will make the file conditionally compiled based on the `HAVE_EMSCRIPTEN` autoconf variable File src/core/logging_emscripten.c: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/b59b3fb4_ffdf2942?usp=email : PS7, Line 24: /*! \addtogroup logging > This file should actually not even compiled in whenever not building for > EMSCRIPTEN. […] Thanks for the suggestion, agreed. I will make the file conditionally compiled based on the `HAVE_EMSCRIPTEN` autoconf variable and drop the `#if defined(__EMSCRIPTEN__)` guard from the source. File src/core/netdev.c: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/72bc8a49_8f6d1a4a?usp=email : PS5, Line 67: #if (!EMBEDDED) && !defined(__EMSCRIPTEN__) > Do you mind sharing why can't you compile netdev. […] To clarify: the first problem is actually a conditional compilation within the source code itself. netdev.c and netns.h contain checks like `#if defined(__linux__)`. But I fixed the build issue by adding some conditional compilations and `USE_NETNS` define in configure.ac. File src/core/socket.c: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/5d221532_bbbc103f?usp=email : PS5, Line 2050: #ifdef HAVE_LIBSCTP > Submit a new separate patch with proper description of the problem and the > fix. Thanks for pointing this out. For now, please ignore those changes — I will remove them from this patch. I plan to prepare separate, dedicated patches addressing these issues in libosmocore and libosmo-netif, as the problem with the HAVE_LIBSCTP guards appears in both libraries. Those follow-up patches will focus solely on fixing the guards properly and can be reviewed independently. https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/ae81cab9_46c318b7?usp=email : PS5, Line 1928: #ifdef HAVE_LIBSCTP > > However, libosmo-netif uses some of them without the same HAVE_LIBSCTP > > guards […] Thanks for pointing this out. For now, please ignore those changes — I will remove them from this patch. I plan to prepare separate, dedicated patches addressing these issues in libosmocore and libosmo-netif, as the problem with the HAVE_LIBSCTP guards appears in both libraries. Those follow-up patches will focus solely on fixing the guards properly and can be reviewed independently. File src/core/socket.c: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/a4e710f1_e6a25a3b?usp=email : PS7, Line 1698: #if defined(__linux__) || defined(__EMSCRIPTEN__) > this is becoming more complex, we should ideally have a configure. […] Agreed. I’ve added a configure-time compile test in configure.ac to detect `struct in6_addr::s6_addr32` and `define HAVE_IN6_ADDR_S6_ADDR32`, and updated the code to use this define. File src/vty/Makefile.am: https://gerrit.osmocom.org/c/libosmocore/+/41813/comment/c085c08c_5ce146f9?usp=email : PS5, Line 36: libosmovty_la_SOURCES += telnet_interface_dummy.c > > In Emscripten there are no sockets so telnet_interface.c fails to compile. > > […] You are right, the issue turned out to be more specific than initially assumed. When I started working on this patch, I did encounter compilation issues related to telnet_interface.c, but unfortunately I can no longer reliably recall the exact cause of those initial failures. After re-testing, telnet_interface.c currently builds fine with Emscripten. Despite the fact that the telnet interface is not needed in a web environment, I have therefore removed telnet_interface_dummy.c and reverted the related changes in src/vty/Makefile.am to keep this patch minimal and focused. I agree that we should only introduce changes once the exact culprit is clearly identified. Any further adjustments related to telnet_interface.c can be handled separately if a concrete issue can be reproduced. -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41813?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31 Gerrit-Change-Number: 41813 Gerrit-PatchSet: 8 Gerrit-Owner: Timur Davydov <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <[email protected]> Gerrit-Reviewer: neels <[email protected]> Gerrit-Reviewer: pespin <[email protected]> Gerrit-CC: laforge <[email protected]> Gerrit-Attention: neels <[email protected]> Gerrit-Attention: laforge <[email protected]> Gerrit-Attention: pespin <[email protected]> Gerrit-Comment-Date: Mon, 19 Jan 2026 13:48:32 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <[email protected]> Comment-In-Reply-To: Timur Davydov <[email protected]>
