This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)