Hi all!
I've been thinking a bit about what kind of code (and directory / library) structure we should be having in order to build the various executables from the functional blocks that we have.
The idea is to prepare for the upcoming / intended new projects while reusing the functional blocks / modules whenver possible.
The graphical structure is at: http://openbsc.osmocom.org/trac/wiki/NewCodeStructure
And the first steps in reorganizing directories and makefiles is available at http://cgit.osmocom.org/cgit/openbsc/log/?h=laforge/new_structure
The new directory structure now has
* directories that contain each one library openbsc/src/{abis,bsc,common,gb,mgcp,msc,trau} * directories that contain code for our daemons (BSC, etc.) openbsc/src/{gprs,osmo-bsc,osmo-bsc_mgcp,osmo-bsc_nat,osmo-nitb} * directories that contain code for utilities openbsc/src/{ipaccess,utils}
There are still some additional/bogus dependencies between the libraries, but I want to fix that and make sure the TRAU directory really only contains code related to the TRAU and RTP frame processing. Some of the generic OML/RSL parsing code should be moved from 'bsc' into the 'abis' directory, etc.
What do you generally think of this? If there is no big complaint, I intend to import Andreas' osmocom-bb.git/jolly/bts code into the openbsc repository (openbsc/src/bts) and start to merge the RTP code into src/trau and the generic bits of RSL+OML into src/abis.
Some random ideas: * prefix the library directories with 'lib', i.e. 'libbsc', 'libmsc' to clearly state this is not a program but just library code * rename the openbsc repository to smething more generic. but what? I don't think we want to create multiple repositories but keep everything in a single repo - at least until one of the sub-libraries is self-contained enough. * should we keep bsc_hack instead of osmo-nitb? (network-in-the-box)? or should it rather be called osmo-niab (network-in-a-box)?
Regards, Harald
Hi,
And the first steps in reorganizing directories and makefiles is available at http://cgit.osmocom.org/cgit/openbsc/log/?h=laforge/new_structure
Mmm, you remove the unused a3a8 code and you re-add it when doing all the git-mv one commit later. I assume it's a manip slip-up.
What do you generally think of this?
Well, IMHO all clean up is good and the structure you laid out makes sense to me.
If there is no big complaint, I intend to import Andreas' osmocom-bb.git/jolly/bts code into the openbsc repository (openbsc/src/bts) and start to merge the RTP code into src/trau and the generic bits of RSL+OML into src/abis.
Why import the BTS code ? Since it's new code, doesn't it make sense to make it directly separate and "well behaved".
It eventually will host the code for: Virtual BTS New BTS BB-BTS (part of it at least, not sure how to split properly) "True" BTS (same issue, not sure how to handle the split)
So that'll be pretty big all by itself.
Some random ideas:
- prefix the library directories with 'lib', i.e. 'libbsc', 'libmsc' to
clearly state this is not a program but just library code
Yes definitly. They already generate libmsc.a and libbsc.a if I'm not mistaken, so it would only be logical to name the directories as such.
- rename the openbsc repository to smething more generic. but what?
I don't think we want to create multiple repositories but keep everything in a single repo - at least until one of the sub-libraries is self-contained enough.
osmo-gsm-net (or corenet) ? This seems to be all all the 'network side' stuff.
- should we keep bsc_hack instead of osmo-nitb? (network-in-the-box)?
or should it rather be called osmo-niab (network-in-a-box)?
Nah, a rename shouldn't be much of an issue IMHO.
As for nitb vs niab, in a google fight "in-the-box" wins vs "in-a-box". I also find the nitb acronym to sound better.
Cheers,
Sylvain
Sylvain,
thanks for your feedback.
On Fri, Mar 04, 2011 at 08:22:38AM +0100, Sylvain Munaut wrote:
And the first steps in reorganizing directories and makefiles is available at http://cgit.osmocom.org/cgit/openbsc/log/?h=laforge/new_structure
Mmm, you remove the unused a3a8 code and you re-add it when doing all the git-mv one commit later. I assume it's a manip slip-up.
good spot, I've re-deleted it.
What do you generally think of this?
Well, IMHO all clean up is good and the structure you laid out makes sense to me.
good.
Why import the BTS code ? Since it's new code, doesn't it make sense to make it directly separate and "well behaved".
My idea was to import it as there is some shared code on the Abis side for RSL and OML message construction (as well as TLV parser definitions) and RTP / TRAU handling. Furthermore, once we'll later start to do GPRS in the BTS, the Gb protocol stack from src/gb/ will also be used in the BTS itself.
But we could just as well use those reasons to make a real 'libosmo-abis.so' either from within openbsc.git or yet another repository. The BTS code could then stay independent and simply link against that library.
So that'll be pretty big all by itself.
Yes, I tend to agree. Keep that seperate and link against abis/trau/gb libraries.
Some random ideas:
- prefix the library directories with 'lib', i.e. 'libbsc', 'libmsc' to
clearly state this is not a program but just library code
Yes definitly. They already generate libmsc.a and libbsc.a if I'm not mistaken, so it would only be logical to name the directories as such.
ok, will do that.
- rename the openbsc repository to smething more generic. but what?
I don't think we want to create multiple repositories but keep everything in a single repo - at least until one of the sub-libraries is self-contained enough.
osmo-gsm-net (or corenet) ? This seems to be all all the 'network side' stuff.
'core network' in GSM means MSC/HLR/VLR/AuC/SMSC but explicitly not the BSC, which is part of the 'radio access netowrk'. So osmo-corenet would be another mis-nomer. osmo-gsm-net may make sense, though.
- should we keep bsc_hack instead of osmo-nitb? (network-in-the-box)?
or should it rather be called osmo-niab (network-in-a-box)?
Nah, a rename shouldn't be much of an issue IMHO.
ok. I just think the _hack suffix is no longer really appropriate and might deter/confuse some users who are not as adventurous as we are ;)
-
Harald Welte -
Sylvain Munaut