Re: [PATCH 1/2] libosmocore: remove GSM-specific functions (they now belong to libosmo-gsm)
Hi,
I forgot to say that VTY code still remains in libosmocore, I'll study if it can be interesting in a new library (I can do this later, once this patches are applied, of course).
gsmtap is a misnomer, but we now use it for TETRA as well ... crc16 possibly common as well (altough not sure).
In general, if we have functions that are common to several protocols but are not really 'system' stuff like select/timer or stuff like that, where should we put them ?
Keep them in libosmocore ? (like a include/osmocom/utils or also in 'core' ?)
Also, for future enhancement (future patches, just mentioning it here since it's kinda related to the whole library cleanup), Harald mentionned to replace the include/osmocore by include/osmocom/core (like it was done for vty / code / ...)
Cheers,
Sylvain
Hi Sylvain,
On 17/03/11 22:15, Sylvain Munaut wrote:
Hi,
I forgot to say that VTY code still remains in libosmocore, I'll study if it can be interesting in a new library (I can do this later, once this patches are applied, of course).
gsmtap is a misnomer, but we now use it for TETRA as well ... crc16 possibly common as well (altough not sure).
So you're proposing that this should go back to libosmocore, right?
In general, if we have functions that are common to several protocols but are not really 'system' stuff like select/timer or stuff like that, where should we put them ?
Keep them in libosmocore ? (like a include/osmocom/utils or also in 'core' ?)
I started with this split, but we can continue with more splits, of course. We can put these into libosmo-utils (or libosmo-base), I don't mind the name.
Also, for future enhancement (future patches, just mentioning it here since it's kinda related to the whole library cleanup), Harald mentionned to replace the include/osmocore by include/osmocom/core (like it was done for vty / code / ...)
Thanks, I'll make follow-up patches for that once these have been applied (I'm trying not to mix things by splitting things in logical changes, to make review easier).
Hi all,
On Thu, Mar 17, 2011 at 10:29:23PM +0100, Pablo Neira Ayuso wrote:
gsmtap is a misnomer, but we now use it for TETRA as well ... crc16 possibly common as well (altough not sure).
So you're proposing that this should go back to libosmocore, right?
Yes, I think those two we can keep in libosmocore for now.
In general, if we have functions that are common to several protocols but are not really 'system' stuff like select/timer or stuff like that, where should we put them ?
Keep them in libosmocore ? (like a include/osmocom/utils or also in 'core' ?)
I started with this split, but we can continue with more splits, of course. We can put these into libosmo-utils (or libosmo-base), I don't mind the name.
I think we should avoid having too much libraries, too. A general split of "this is really GSM/GPRS/EDGE/3G related" and "this is common system-level code like select/timer/msgb handling" makes sense. But going even further is probably not worth it, otherwise we end up having too many libraries.
Also, building all of the libraries from a single source repository (like we now build libosmovty as part of the libosmocore.git) may be the right approach.
Having to clone + update lots of different repositories just makes development and compilation fort he users more difficult.
Also, for future enhancement (future patches, just mentioning it here since it's kinda related to the whole library cleanup), Harald mentionned to replace the include/osmocore by include/osmocom/core (like it was done for vty / code / ...)
Thanks, I'll make follow-up patches for that once these have been applied (I'm trying not to mix things by splitting things in logical changes, to make review easier).
I agree to both: * move include files from include/osmocore/8 to include/osmocom/... * that it is good to do this in separate patches.
-
Harald Welte -
Pablo Neira Ayuso -
Sylvain Munaut