Hi Pablo,
On Sun, May 08, 2011 at 06:57:37PM +0200, Pablo Neira Ayuso wrote:
I think now
that the namespace issues in libosmocore have been resolved,
we seriously have to think of maintaining a stable API and ABI. This
allows us to have truly independent library and application releases,
and the dynamic linker library versioning support should ensure
compatibility.
Would it be worth if we make opaque declaration of some structures
opaque? e.g. struct osmo_timer_list in the header file, and the real
declaration in
I think this would be too much at this point. I also think we don't
have any 'illegitimate' use of the structures, and we are only using the
libraries from a couple of programs that all come 'from the same family'
I think that we should also use a map file [1] and the
EXPORT_SYMBOL
declaration [2].
same here. I think for now it only creates additional work without much
benefit from it. The EXPORT_SYMBOL stuff only becomes interesting once
we have calls to private functions between multiple .o files.
Rigth now off my head they only case where this would make practical
sense is for libosmovty, where we have lots of buffer.c and cmd.c calls
from within vty.c which shouldn't be public at all. I would definitely
welcome a patch to that regard.
Rather than spending time on map files and private/public header files,
I would be more open to some kerneldoc or doxygen comments in the code,
in order to generate some official libosmocore API documentation.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)