18 Mar
2011
18 Mar
'11
12:49 p.m.
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).