Dear Community People.
Some people are asking about next plan. I didn't answer correctly because I don't know how much time I have or how much my abilities are possible. But now I think I need to start sharing what I want to do.
I don't know if it's possible to this, but I'd just like to prepare to move 5G Core. But there are a lots of things before that and I don't know exactly when this project is going on.
Anyway, in order to share the code used by 4G/5G, I will separate the repository as follows:
Repo1 : libogscore - apt install libogscore-dev
Repo2 : libogs-asn1c - common : apt install libogs-asn1c-common-dev - s1ap : apt install libogs-asn1c-s1ap-dev
Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev - libfdcore - libfdproto
Repo4 : libogslib - apt install libogslib-dev - s1ap : apt install libogs-s1ap-dev DEPEND libogs-asn1c-common-dev libogs-asn1c-s1ap - nas : apt install libogs-nas-dev - gtp : apt install libogs-gtp-dev - diameter : apt install libogs-diameter-dev DEPEND libogs-freeDiameter-dev - app : apt install libogs-app-dev
Repo5 : ogs-mme - apt install ogs-mme ; DEPEND libogs-app-dev libogs-s1ap-dev libogs-nas-dev libogs-gtp-dev libogs-diameter-dev Repo6 : ogs-hss - apt install ogs-hss ; DEPEND libogs-app-dev libogs-diameter-dev Repo7 : ogs-pcrf - apt install ogs-pcrf ; DEPEND libogs-app-dev libogs-diameter-dev Repo8 : ogs-sgw - apt install ogs-sgw ; DEPEND libogs-app-dev libogs-gtp-dev Repo9 : ogs-pgw - apt install ogs-pgw ; DEPEND libogs-app-dev libogs-gtp-dev libogs-diameter-dev
Repo10 : ogs-epc ; if all stuff are available, current nextepc repo is changed to ogs-dev for managing issues list
This approach is similar to the osmocom project. In fact, I'm not sure whether this is good or not. However, osmocom manages 2G/3G like this and I believe that experience.
So I'll do it from now.
P.S. Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;
Thanks a lot!
Best Regards, Sukchan
Hi Sukchan,
thanks for sharing your thoughts.
On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
Anyway, in order to share the code used by 4G/5G, I will separate the repository as follows: [...]
In general, I think it may make sense to split things up, but only to the extent that the related [library] code is really going to be used by multiple applications which logically don't belong together.
I currently don't know sufficiently about 5G to know how much of the existing code would be needed in a 5G core. For example, I don't think DIAMETER is used in a true/native 5G core.
This approach is similar to the osmocom project. In fact, I'm not sure whether this is good or not. However, osmocom manages 2G/3G like this and I believe that experience.
Beware there are consequences. For example, if you have libraries in a separate repository, you must be very careful about maintaining ABI and API compatibility, as well as managing LIBVERSION properly. This means in general it's best to never modify any existing symbol (function) but to only introduce new ones. Otherwise a library upgrade without application upgrade would break.
Also, you typically want to ensure backwards API compatibility, so that any old application can be build with any new library version. In order to ensure this, it is best to have automatic testing that e.g. builds all old/existing tags of applications against the 'master of the day' of libraries.
So given the limited resources (time/developers), it requires careful thinking whether all the related overhead makes sense. Some things can be automatized, but it also requires quite a bit of discipline from the developer[s]. So be warned :P
Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;
I think it's a good idea to avoid nextepc naming confusion related to the U.S. entity nextepc inc. using an older codebase and your new project.
I agree it is a good idea to separate any shared libraries into separate repositories, but only *if* they are used by multiple other repositories, and if you are committed to providing a rather stable API and ABI.
I am not sure if moving towards the full set of repositories as described is the best choice at this point. It might be an idea to only separate those which you will need from your new 5G core elements?
by the way: When creating the new repositories, make sure the git history remains. You can create the new repositories using 'git filter-branch' of the current nextepc.git repository, keeping the history of all the relevant commits. Finally, you can then rename/move files in one new commit.
The git commit history is just as important or sometimes even more important for any future developers than the actual code.
Of course the above is just my opinion. It's your project, you get to decide :)
Regards, Harald
See inline below.
On Tue, Aug 27, 2019 at 5:10 AM Harald Welte laforge@gnumonks.org wrote:
Hi Sukchan,
thanks for sharing your thoughts.
On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
Anyway, in order to share the code used by 4G/5G, I will separate the repository as follows: [...]
In general, I think it may make sense to split things up, but only to the extent that the related [library] code is really going to be used by multiple applications which logically don't belong together.
I currently don't know sufficiently about 5G to know how much of the existing code would be needed in a 5G core. For example, I don't think DIAMETER is used in a true/native 5G core.
Also I don't enough knowledge of 5G Core either. I really want to remove the freeDiameter library in 5G. But DIAMETER still needs to connect the IMS core on 5G. If true, I need to separate freeDiameter and NextEPC.
This approach is similar to the osmocom project. In fact, I'm not sure whether this is good or not. However, osmocom manages 2G/3G like this
and I
believe that experience.
Beware there are consequences. For example, if you have libraries in a separate repository, you must be very careful about maintaining ABI and API compatibility, as well as managing LIBVERSION properly. This means in general it's best to never modify any existing symbol (function) but to only introduce new ones. Otherwise a library upgrade without application upgrade would break.
Also, you typically want to ensure backwards API compatibility, so that any old application can be build with any new library version. In order to ensure this, it is best to have automatic testing that e.g. builds all old/existing tags of applications against the 'master of the day' of libraries.
So given the limited resources (time/developers), it requires careful thinking whether all the related overhead makes sense. Some things can be automatized, but it also requires quite a bit of discipline from the developer[s]. So be warned :P
I missed the library compatibility part. In split repository, I agreed that it would be really hard to manage this. Hmm..IMHO, I need to reduce the number of library since my time and ability is limited.
Please, feel free to give any idea the above plan. Expecially, 'NAMING'.
^^;
I think it's a good idea to avoid nextepc naming confusion related to the U.S. entity nextepc inc. using an older codebase and your new project.
I agree it is a good idea to separate any shared libraries into separate repositories, but only *if* they are used by multiple other repositories, and if you are committed to providing a rather stable API and ABI.
I am not sure if moving towards the full set of repositories as described is the best choice at this point. It might be an idea to only separate those which you will need from your new 5G core elements?
by the way: When creating the new repositories, make sure the git history remains. You can create the new repositories using 'git filter-branch' of the current nextepc.git repository, keeping the history of all the relevant commits. Finally, you can then rename/move files in one new commit.
The git commit history is just as important or sometimes even more
important for any future developers than the actual code.
I will do it definitely!
Of course the above is just my opinion. It's your project, you get to
decide :)
I'm really appreciated for your comments. From your advice, I'll revise the REPO like the followings.
Repo1 : libogscore - apt install libogscore-dev
Repo2 : libogs-asn1c - common : apt install libogs-asn1c-common-dev - s1ap : apt install libogs-asn1c-s1ap-dev
Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev - libfdcore - libfdproto
Repo4 : Changes nextepc to ogs-epc.
Best Regards, Sukchan
Regards,해
Harald--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Sukchan Lee