Re: [PATCH 1/2] libosmocore: remove GSM-specific functions (they now belong to libosmo-gsm)
17 Mar
2011
17 Mar
'11
10:15 p.m.
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
17 Mar
17 Mar
10:29 p.m.
New subject: [PATCH 1/2] libosmocore: remove GSM-specific functions (they now belong to libosmo-gsm)
Hi Sylvain,
On 17/03/11 22:15, Sylvain Munaut wrote:
Hi,
So you're proposing that this should go back to libosmocore, right?
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' ?)
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).
18 Mar
18 Mar
12:49 p.m.
New subject: [PATCH 1/2] libosmocore: remove GSM-specific functions (they now belong to libosmo-gsm)
Hi all,
On Thu, Mar 17, 2011 at 10:29:23PM +0100, Pablo Neira Ayuso wrote:
Yes, I think those two we can keep in libosmocore for now.
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.
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 <laforge(a)netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
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).
5209
days inactive
5210
days old
2 comments
3 participants
participants (3)
-
Harald Welte -
Pablo Neira Ayuso -
Sylvain Munaut