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/.
Pablo Neira Ayuso pablo at gnumonks.orgHi Harald, On Thu, Sep 29, 2011 at 09:02:03AM +0900, Harald Welte wrote: > On Tue, Sep 27, 2011 at 02:47:12PM +0200, Pablo Neira Ayuso wrote: > > This new library, whose proposed name can be "libosmo-net", would > > initially support: > > > > - E1 interfaces. > > - Ethernet + IPA TCP/IP. > > - rs232 (as required by bs11 its config interface). > > > > This support is included in libosmo-abis, so my idea is to extract > > this code from it and leave in libosmo-abis only the specific A-bis > > bits. > > I'm not sure if such a split is practical. What exactly woould remain > A-bis specific? The TRAU frame handling for voice channels? And other signalling bits, but yes, it would be fairly small library. > > For the A interface, I'd propose some hypothetical libosmo-a library > > that will contain the specific A interface protocols. > > Once again I'm not entirely convinced that this is neccessarry. We > already have libosmo-sccp for the SCCP parsing routines, and the > BSSAP/BSSMAP layer is handled in osmo-bsc directly. So I don't really > see what would be left over as A-specific parts. > > In order to stop further proliferation of small library fragments, I > would rather suggest to include any (if at all) remaining A-bis and A > related parts in the same libosmo-net. OK, we can put all in the same library. 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, ...); int osmo_netif_close(struct osmo_netif *if); int osmo_netif_read(struct osmo_netif *if, ...); int osmo_netif_enqueue(struct osmo_netif *if, ...); int osmo_netif_write(struct osmo_netif *if, ...); This would allow to open one net interface of some type, and use it to receive and to send information over it, no matter in it's on the A-bis, A, ... GSM interface. My preliminary planning could be: 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. Following this approach, we can support several network interfaces in the A interface soon. Then, we can spend time to supersede libosmo-abis. Or you consider that the e1input infrastructure is already flexible enough to support the A interface with relatively minor changes? I'm not sure. > btw: I'm still trying to come up with a better name. libosmo-signalling > is wrong as it will also deal with voice/trau/rtp. libosmo-interface > maybe? Also not a quite obvious naming. libosmo-netif as a compromise? libosmo-netif sounds fine to me.