Follow-up commits will add some extra checks we want to have in config.h
Include config.h in files using PACKAGE_VERSION.
Change-Id: Ic779a3168012780feef8d173371387d09d383bfd
This allows apps to allocate the objects as they please: simple apps can
statically allocate it at startup. Others may want to allocate them
through VTY.
Some apps may also want to dynamically start and stop layer2.
Change-Id: I32f99df76a5513eff9df5489d28d60aedf96dec3
Found by clang:
l1ctl.c:397:52: warning: implicit conversion from 'int' to 'int8_t'
(aka 'signed char') changes value from 255 to -1
[-Wconstant-conversion]
Change-Id: I23e9ea5ad59099c24db60057c8e7da1e6a0d2293
The only caller of gsm_settings_exit() is in app_mobile so far, which is
the only app supporting/using lua scripting so far.
Change-Id: I634a4514ead9d064e7509c3fbbb3a2c89c7f3a56
A small layer23 framework is added which allows apps to easily share/reuse
VTY commands while giving some flexiblity to add new per-app
specific configs/cmds, since not all commands may be relevant for all
apps.
Some of the mobile app code is moved to common, and sample infra is
added to modem app.
Future commits will most probably keep moving more stuff mobile->common
and then reusing those in modem app, as found needed.
Change-Id: Iabfb3129199488d790b89884bc1e424f2aca696f
This way we can extend its API and contents more easily,
and keep most of it together in one place.
Change-Id: Icb4891cc1e4a0ecb5f09cb8a84b0ebe1b91a46b8
Initial VTY "boilerplate" code for modem app is already added in
this commit as a showcase what's needed by an app to have the VTY
config file read and VTY interface initialized.
Change-Id: Ife3a3373e5a9c0c8e5959ac714e140e72d6c363a
This commit is a preparation towards having shared VTY infrastructure
for layer23 apps. Having 2 steps (first init(), then start()) allows
the apps easily struct allocation & initialization, and then start doing
work after VTY config has been read.
Change-Id: I1d232809764962f82fee86159bc61cdbc3eb3c48
There was no need for this check because the channel establishment
logic was at the end of handle_si13(), so I overlooked this.
Change-Id: I829948de325461ab5d7e950493497a7537ba06ac
Fixes: 8a506dcd4e
Related: OS#5500
Sending CHANNEL REQUEST from handle_si13() was a bad idea because
this function returns early if SI13 was received before SI1.
Change-Id: I21f1d68cb9b1d20b356697ba1efe28c3d87fa004
Fixes: 49d993e4ab
Related: OS#5500
Triggered with gcc 12.2.0:
/osmocom-bb/src/host/layer23/src/common/sysinfo.c: In function ‘gsm48_sysinfo_dump’:
/osmocom-bb/src/host/layer23/src/common/sysinfo.c:198:42: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
198 | sprintf(buffer + 69, " %d", i + 63);
| ^
/osmocom-bb/src/host/layer23/src/common/sysinfo.c:198:17: note: ‘sprintf’ output between 3 and 13 bytes into a destination of size 12
198 | sprintf(buffer + 69, " %d", i + 63);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I29a64fbb7aca0d1b469b6d278d4a24ddc6f57b3a
Use the existing application skeleton from '$(top_srcdir)/src/common/'.
Use the LAPDm glue from '$(top_srcdir)/src/misc/rslms.c'.
This is what the misc applications like ccch_scan are using.
Change-Id: I8566a3cdc9f818bed7e28ea4b1957dce735c298b
Related: SYS#5500
What I find weird is that the gsmmap is using files from layer23,
and vice-versa cell_log from layer23 is using files from this
utility. And somehow they are separate sub-projects.
I see no reason why gsmmap must be in its own sub-project.
Change-Id: I2bc9c8897f3c7ccf207be0146f7b55fc733a6abb
This will be needed for the modem application, and is also used
in a follow-up commit adding support for parsing SI13 Rest Octets.
Change-Id: I8e0f826c9b2a886f94624176e34e7d197e93d25f
Related: OS#5500
Accessing a header file from outside of the sub-project requires
using the relative path ("-I$(top_srcdir)/../layer23/include"),
which does not resolve properly during make distcheck.
The '../layer23/include/l1ctl_proto.h' is actually a symlink too.
Change-Id: Id64ab161a17d53f5e93cdd100e81d4fb8acfb97a