Harald Welte
2014-08-20 18:12:40 UTC
Hi Daniel,
I am currently working on moving the control interface to libosmocore,
you can find the status in the 'laforge/libctrl' branch. The reason
behind this is that I will be adding a control interface to osmo-bts
soon.
The first dozens of commits is basically a filtered list of commits from
the openbsc repository. The last few commits are towards making it
build outside libosmocore.
Most of the commits are pretty simple and uninteresting. However, there
is one change that I would like to ask you to review:
adf2530fc3c9d45dd1d528cd6d92d462702e3f19 where I'm trying to avoid using
the openbsc-global 'tall_bsc_ctx' and introduce a more hierarchical
inheritance of allocations. As this is the first time I've looked at
the control interface, I might have made some wrong decisions there.
The remaining steps are:
* remove 'struct gsm_network' as reference and replace with a 'void *
data' or 'void *priv' field
* possibly rename/prefix the function names, so we end up with
osmoctrl_* for the symbol names.
Regards,
Harald
I am currently working on moving the control interface to libosmocore,
you can find the status in the 'laforge/libctrl' branch. The reason
behind this is that I will be adding a control interface to osmo-bts
soon.
The first dozens of commits is basically a filtered list of commits from
the openbsc repository. The last few commits are towards making it
build outside libosmocore.
Most of the commits are pretty simple and uninteresting. However, there
is one change that I would like to ask you to review:
adf2530fc3c9d45dd1d528cd6d92d462702e3f19 where I'm trying to avoid using
the openbsc-global 'tall_bsc_ctx' and introduce a more hierarchical
inheritance of allocations. As this is the first time I've looked at
the control interface, I might have made some wrong decisions there.
The remaining steps are:
* remove 'struct gsm_network' as reference and replace with a 'void *
data' or 'void *priv' field
* possibly rename/prefix the function names, so we end up with
osmoctrl_* for the symbol names.
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)