Hi Pablo,
On Thu, Sep 29, 2011 at 02:33:28PM +0200, Pablo Neira Ayuso wrote:
In order to re-use the existing networking interfaces
in any GSM
interface, I'm thinking about extracting some code from the e1input
infrastructure and provide some generic API to create, destroy, write
and read data, something like:
#define OSMO_NETIF_T_NONE 0
#define OSMO_NETIF_T_DAHDI 1
#define OSMO_NETIF_T_MSISDN 2
#define OSMO_NETIF_T_IPA 3
#define OSMO_NETIF_T_RS232 4
#define OSMO_NETIF_T_WHATSOEVER 5
struct osmo_netif *osmo_netif_open(int type, ...);
I think this should probably be a _reconfig() function, i.e. something
that can process incremental changes to the configuration. It is very
likely that the BSC process runs for a long time, and the E1 timeslot
configuration / or other signallign configuration changes during
runtime. So an initial "open" is not really sufficient.
The _reconfig() calls could be triggered every time we "exit" from the
VTY node that configures the like or signalling-link.
I also think that the _open() / _reconfig() call could be device type
specific, i.e. something like
struct osmo_netif *osmo_netif_open_dahdi(...);
struct osmo_netif *osmo_netif_open_ipa(...);
...
as the parameters will probably be _very_ device type specific, it might
not make sense to put all of it in one large union of structures.
Also, I expect almost all users to use VTY for configuration, so we
should have library-internal VTY support where we could have something
like this for the VTY parsing inside the library:
% a real circuit A-bis line on E1 (BS-11, Ericsson RBS, ..)
line AbisLine0
description Foobar
driver dahdi
[driver-specific parameters]
% a real circuit A line on E1
line ALine0
description ...
driver misdn
[driver-specific parameters]
% a virtual A line over IPA
line Aline1
description ...
driver ipa-client
ipa-client remote-ip A.B.C.D
ipa-client remote-port <0-65535>
ipa-client unit-id 1234 0
ipa-client authot-ken AbCdEf
% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvOML0
description Foobaz
driver ipa-server
ipa-client local-ip A.B.C.D
ipa-client local-port 3003
% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvRSL0
description Foobaz
driver ipa-server
ipa-client local-ip A.B.C.D
ipa-client local-port 3002
signalling-link ALine0/0
description MyMscLink
timeslot 1 sub-slot full
encapsulation mtp
[mtp-specific parameters]
signalling-link AbisLine1/0
description MyBtsLink
e1_timeslot 1 sub-slot full
encapsulation lapd
and then something like this (for the BSC):
bsc
a-interface signalling-link ALine0/0
% A BS-11
bts 0
oml tei 25
oml signalling-link Line1/0
trx 0
rsl tei 0
rsl signalling-link Line1/0
% an ip.access nanoBTS
bts 1
oml tei 255 % IPA stream ID
oml line AbisSrvOML0
oml ipa unit-id 1800 0
trx 0
rsl tei 0 % IPA stream ID
rsl line AbisSrvRSL0
rsl ipa unit-id 1800 0
1) Rip code from libosmo-abis (input drivers) to
implement this new
API in libosmo-netif.
2) Port openbsc to use this new API in the A interface.
3) Finally, put libosmo-abis into libosmo-netif. After that, we can
consider libosmo-abis obsolete.
I think the existing libosmo-abis API might very well disappear, OpenBSC
should use the netif library directly even for Abis
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)