I am currently setting up separate repositories to replace openbsc.git.
Aspects: - choice how to separate - apply 3G and AoIP changes to do code review
My plan is to separate openbsc.git into these parts:
osmo-msc.git = OsmoMSC
osmo-bsc.git = OsmoBSC, OsmoBSCNAT
osmo-sgsn.git = OsmoSGSN, OsmoGTPHUB
osmo-mgw.git = new OsmoMGW, at first plain renamed from osmo-bsc_mgcp + libosmo-mgcp
Each of these will contain the full openbsc.git history to be able to follow changes back in the log easily.
The libmgcp has so far been internal to openbsc.git. I intend to make it an installed library from osmo-mgw.git (similar to libosmo-ranap from osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not been aware of until now.
libiu, shared between MSC and SGSN, has already moved to osmo-iuh.
The other thing the MSC and SGSN still share is the GSUP client. The GSUP protocol code has already moved to libosmocore, but the gsup_client is still in openbsc. I believe it is appropriate to move the gsup_client along to libosmocore, even though the notion so far has been to keep it out of there. Otherwise we either duplicate the gsup_client or need another separate libosmo-gsupclient.
Possibly other code needs to be moved around similarly, but AFAICT "decreasing in importance".
Code review:
We can review in various ways. I believe the least troublesome would be this: - create osmo-msc git from the current openbsc. - remove the top level 'openbsc' dir. - go through all of the patches in gerrit to apply to 'master', which will apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW, all of these in osmo-msc.git. - the state thus reached is the basis for the split. Copy this to osmo-*.git - in each separate git, remove the files not needed for that particular project. Remove possible remaining code duplication as we go.
openbsc.git | | copy v osmo-msc.git | | - `mv openbsc/* .` v | gerrit code review: | +VLR | +3G | +AoIP | +------------------------------- | | v | ----------copy-------- | | | | | v v v | osmo-bsc osmo-sgsn osmo-mgw osmo-msc | | | | | | | | clean unrelated files v v v v
continue ongoing development from these new master HEADs
I'm currently playing through the separation, osmo-msc with top-level openbsc removed is done, osmo-mgw and osmo-bsc pending. This means that I will need to apply commits merged to openbsc from now on to the new separate gits until we move over for good. That's fairly similar to keeping the 3G,AoIP branch rebased onto openbsc master as we did previously. It may make sense to focus AoIP development onto the new repositories soon.
So far I'm keeping the gits privately on a sysmocom office machine. We could also open up new osmo-* repositories on gerrit and git.osmocom.org now.
~N
Excellent news!
On top of that I propose to switch old openbsc.git to read-only the moment new repositories are public to make sure people use proper HEADs for development right away.
Also, we should remove conflicting .deb packaging before enabling nightly builds for split repositories - do we have a separate ticket for that?
10.07.2017 17:33, Neels Hofmeyr пишет:
So far I'm keeping the gits privately on a sysmocom office machine. We could also open up new osmo-* repositories on gerrit and git.osmocom.org now.
~N
Hi Neel,s
On Mon, Jul 10, 2017 at 05:33:14PM +0200, Neels Hofmeyr wrote:
I am currently setting up separate repositories to replace openbsc.git.
great.
The libmgcp has so far been internal to openbsc.git. I intend to make it an installed library from osmo-mgw.git (similar to libosmo-ranap from osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not been aware of until now.
I think we have to be careful to review its API in detail before making it a public, system-installed library where we have to deal with API or ABI breakage of anything we modify later on.
One idea that Holger formerly pursued with libsccp.a was to only have static libraries - we might revisit that idea if we cannot go through related API review.
libiu, shared between MSC and SGSN, has already moved to osmo-iuh.
I presume it is then called libosmo-iu ?
The other thing the MSC and SGSN still share is the GSUP client. The GSUP protocol code has already moved to libosmocore, but the gsup_client is still in openbsc. I believe it is appropriate to move the gsup_client along to libosmocore, even though the notion so far has been to keep it out of there.
The problem is again API/ABI stability. It restricts the way we can use code, and I would prefer to avoid constraining ourselves...
Otherwise we either duplicate the gsup_client or need another separate libosmo-gsupclient.
I don't like the latter part.
Code review:
We can review in various ways. I believe the least troublesome would be this:
- create osmo-msc git from the current openbsc.
- remove the top level 'openbsc' dir.
- go through all of the patches in gerrit to apply to 'master', which will apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW, all of these in osmo-msc.git.
- the state thus reached is the basis for the split. Copy this to osmo-*.git
- in each separate git, remove the files not needed for that particular project. Remove possible remaining code duplication as we go.
makes sense.
So far I'm keeping the gits privately on a sysmocom office machine. We could also open up new osmo-* repositories on gerrit and git.osmocom.org now.
No need to keep it private. Feel free to put it on git.osmocom.org.
Good luck!
On Tue, Jul 11, 2017 at 09:09:37PM +0200, Harald Welte wrote:
The libmgcp has so far been internal to openbsc.git. I intend to make it an installed library from osmo-mgw.git (similar to libosmo-ranap from osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not been aware of until now.
I think we have to be careful to review its API in detail before making it a public, system-installed library where we have to deal with API or ABI breakage of anything we modify later on.
One idea that Holger formerly pursued with libsccp.a was to only have static libraries - we might revisit that idea if we cannot go through related API review.
I'm not really aware how a dynamically linked libosmo-mgcp has more problems than a static one. About the API I notice that there is a header called mgcp_internal.h, with a comment "Private data" at the top, suggesting that it would be used only within mgcp*.c; but osmo-bsc_nat wants to use that header file and its functions, so I added this header to the install. This just to say that indeed there may be some review, renaming, rearranging at hand.
My idea is to first get it to work with as little modifications as possible (besides renaming directories / larger scopes), and refine the structure later. The review process may become rather important...
libiu, shared between MSC and SGSN, has already moved to osmo-iuh.
Correction: I thought that we had already merged it, but in fact it's still on a private branch of mine. Now https://gerrit.osmocom.org/3187
I presume it is then called libosmo-iu ?
What our libiu does is actually dock fairly tightly to libosmo-ranap, providing the code that each of the Iu interfaces use commonly to act as a RANAP endpoint. Hence I decided to include it in libosmo-ranap as iu_client_*.
One reason to indeed want to separate it again could be that it uses libosmo-sigtran, accepting an sccp instance like this:
int ranap_iu_init(void *ctx, int log_subsystem, const char *sccp_user_name, struct osmo_sccp_instance *sccp, ranap_iu_recv_cb_t iu_recv_cb, ranap_iu_event_cb_t iu_event_cb)
Including in libosmo-ranap was the simplest way to go. The osmo-iuh build depends on libosmo-sigtran anyway because of OsmoHNBGW, and all users of libosmo-ranap also naturally link libosmo-sigtran already.
I believe it is appropriate to move the gsup_client along to libosmocore, even though the notion so far has been to keep it out of there.
The problem is again API/ABI stability. It restricts the way we can use code, and I would prefer to avoid constraining ourselves...
Otherwise we either duplicate the gsup_client or need another separate libosmo-gsupclient.
I don't like the latter part.
Are you implying that we should indeed duplicate?
The same rationale could actually apply to above iu client.
I don't know; Yes, it's not really that much code to duplicate, but keeping separate copies of entire APIs feels undesirable. Is modifying the API/ABI really such a big problem? "Simply" keep older function signatures, possibly deprecate some, possibly even make a breaking change and depend on new library versions occasionally ... isn't that expected daily business?
~N
-
Harald Welte -
Max -
Neels Hofmeyr