29 Apr
2016
29 Apr
'16
4:17 p.m.
On 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