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 compatibility.
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 http://www.gnu.org/software/libtool/manual/libtool.html#Versioning 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.
Regards, Harald
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 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
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 http://www.gnu.org/software/libtool/manual/libtool.html#Versioning 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 [1] and the EXPORT_SYMBOL declaration [2].
I can make a patch to support this.
These references point to libmnl as one example of mine:
[1] http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/libmnl... [2] http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/intern...
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 -
Pablo Neira Ayuso