On Thu, Aug 28, 2025 at 02:25:29PM +0200, Alexander 'lynxis' Couzens wrote: > a couple month ago I proposed to make the VLR code of the osmo-msc > independent of the osmo-msc > and create a new library called libosmo-vlr. Later use the libosmo-vlr code > to integrate it into > osmo-sgsn.
A separate libosmo-vlr would be the idealistic optimum. But I think the most important part is that, instead of starting a new VLR implementation from scratch, to use what we learned in osmo-msc and use that in osmo-sgsn. So if there is too much complexity in marrying msc and sgsn to a common libosmo-vlr, I'd personally agree with adding a copy of the MSC's VLR into the SGSN and just make it work from there, without idealistic expectations on having a fully independent external library. I myself did once try to create libiu-client to share Iu interface handling between SGSN and MSC, which was a great idea in my nerdy dreams, but only held us back in practice. We've finally recently gotten rid of it. The vlr in osmo-msc does try to do proper layer separation, with those vlr_ops callback functions and so on. So the vision *was* to be independent from the MSC's code. But did it work out? It would be interesting for me personally to take a closer look at the individual places that cause problems, to see the places where the MSC's VLR isn't properly separated, after all. Maybe we can even resolve those problems, but, I still think just keeping an own VLR copy in osmo-sgsn is a very good option, too. If we ever make important fixes to the VLR, copying those fixes over between SGSN and MSC, and otherwise allowing them to slightly diverge, will very likely be less work than constantly keeping both VLRs in sync. The VLR is not libosmocore... > PS. The current concept (because of time pressure) is to keep 2 copies of > libosmo-vlr in the code base of osmo-msc and osmo-sgsn and to move it later > out of it into an own library. (...and i would also be fine with not bothering to move it out later.) > I would rather guarantee runtime stability within a library version, but not > at build time. The strategy would be increasing the library major version > more often. (I don't understand this paragraph, I hope I gave a sufficient answer above) ~N
