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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Thu, Apr 28, 2016 at 02:52:12PM +0200, Harald Welte wrote: > It was clearly not the intention to keep the code out of master for more > than the time it takes to implement those features. > > So yes, very clearly, for the CS side the NITB has to stay intact after > a merge of the Iu, until the A interface is implemented. So please > don't think of this as something "far down the line". This is a very high level decision. So far the explicit goal was to replace CSCN's libbsc with a proper A interface. So instead of placing junctures to decide whether to use BSC land structures (like the bts pointer) or not, I removed BSC land references. The A-interface aim is more neat in the sense that we will have explicit junctures that can decide whether to send a given message to A or IuCS. This obviously removes some NITB direct-BSC-access features. OTOH, the NITB-with-IuCS would be more like the tightly connected MSC+BSC with an IuCS side channel "stuck to its side". It's then questionnable whether to remove the direct-BSC-access features at all. Implementing the A-interface is clearly more work before being able to merge. But if we are going to sacrifice NITB for an A-interface anyway, it would be overall less work to keep NITB and IuCS separate until A is done. Keeping the NITB requires some un-rewiring, talking about the changes to gsm_subscriber_connection and reverting a few clear cuts from the previous code paths that I so far have in the iu branch. Shouldn't be too much work really. However, to me, keeping the NITB along with IuCS does sound like a complete change of direction compared to the previous instructions you gave me, i.e. to go for an A. Either way is fine, but let's be clear on which is the goal! Thinkable would also be to have all three: IuCS, NITB and a future A interface. That is to a degree sacrificing the neat clarity of separating MSC and BSC for good, and it would be the non-UNIX style "Eierlegende Wollmilchsau" [1]. These are my thoughts on CS so far, I am happy to go whichever way the community prefers. Let's establish consensus on the goal/roadmap as soon as possible. My wish to review the branch diff so far is still valid and probably goes hand in hand with this decision. It might be good if I have a look at the key junctures in the code paths and send a report/overview to this list? > For the PS side, I don't see any reason at all why a merge to master > should be postponed much longer. Yes, of course depending on Daniel's opinion, this is a completely different thing and merging is less of a complex decision. ~Neels [1] https://en.wiktionary.org/wiki/eierlegende_Wollmilchsau -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160429/c7a4dbc6/attachment.bin>