[ANN] libosmocore stable API/ABI

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun May 8 17:42:55 UTC 2011


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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list