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
- Rip code from libosmo-abis (input drivers) to implement this new API in libosmo-netif.
- Port openbsc to use this new API in the A interface.
- 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