[ANN] libosmocore stable API/ABI
Pablo Neira Ayuso
pablo at gnumonks.org
Sun May 8 18:57:37 CEST 2011
On 08/05/11 14:20, Harald Welte wrote:
> Hi all!
> 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
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
Encapsulation is good to avoid breaking backward compatibility. Not sure
if we expect that this structure would ever change.
Let me know if I'm being too conservative :-).
> So please think twice about any modifying libosmocore. It is safe to
> add new functions, but we cannot change the prototypes (number of
> arguments) for existing functions.
> As soon as new functions are introduced, we should increment the library
> interface number.
> For more information, see
> especially the rules in Chapter 7.3:
> # If the library source code has changed at all since the last update,
> then increment revision (‘c:r:a’ becomes ‘c:r+1:a’).
> # If any interfaces have been added, removed, or changed since the last
> update, increment current, and set revision to 0.
> # If any interfaces have been added since the last public release, then
> increment age.
> # If any interfaces have been removed or changed since the last public
> release, then set age to 0.
I think that we should also use a map file  and the EXPORT_SYMBOL
I can make a patch to support this.
These references point to libmnl as one example of mine:
More information about the baseband-devel