On Wed, 2009-08-19 at 21:57 -0700, Steven Dake wrote:
> On Thu, 2009-08-20 at 06:39 +0200, Fabio M. Di Nitto wrote:
> > This change the API and ABI for cpg.
> >
> > Before this change can go anywhere, it needs proper Makefile.am love or
> > even easier queue it after libtool changes that makes slightly easier to
> > have per library API and ABI versioning.
> >
> > Let's try, as a general rule, to avoid the same nightmare we had between
> > whitetank and current status with hidden API/ABI changes.
> >
> > Fabio
> >
>
> The addition of API calls are allowed in Y releases, and those additions
> don't result in a soname bump.
I am not discussing if they are allowed or not. I know they are allowed.
> > > > diff --git a/trunk/include/corosync/ipc_cpg.h
> > > > b/trunk/include/corosync/ipc_cpg.h
> > > > index 1d240d4..7df1891 100644
> > > > --- a/trunk/include/corosync/ipc_cpg.h
> > > > +++ b/trunk/include/corosync/ipc_cpg.h
> > > > @@ -45,6 +45,9 @@ enum req_cpg_types {
> > > > MESSAGE_REQ_CPG_MCAST = 2,
> > > > MESSAGE_REQ_CPG_MEMBERSHIP = 3,
> > > > MESSAGE_REQ_CPG_LOCAL_GET = 4,
> > > > + MESSAGE_REQ_CPG_ITERATIONINITIALIZE = 5,
> > > > + MESSAGE_REQ_CPG_ITERATIONNEXT = 6,
> > > > + MESSAGE_REQ_CPG_ITERATIONFINALIZE = 7
> > > > };
> > > >
> > > > enum res_cpg_types {
> > > > @@ -56,7 +59,10 @@ enum res_cpg_types {
> > > > MESSAGE_RES_CPG_DELIVER_CALLBACK = 5,
> > > > MESSAGE_RES_CPG_FLOW_CONTROL_STATE_SET = 6,
> > > > MESSAGE_RES_CPG_LOCAL_GET = 7,
> > > > - MESSAGE_RES_CPG_FLOWCONTROL_CALLBACK = 8
> > > > + MESSAGE_RES_CPG_FLOWCONTROL_CALLBACK = 8,
> > > > + MESSAGE_RES_CPG_ITERATIONINITIALIZE = 9,
> > > > + MESSAGE_RES_CPG_ITERATIONNEXT = 10,
> > > > + MESSAGE_RES_CPG_ITERATIONFINALIZE = 11,
> > > > };
^^^ this is the problem.
You are changing the internal API/ABI of the library towards the
executive/service.
Unless you want to make sure that those values are totally optional,
then you need to bump the soname to make sure executive version that
handles those values is correctly linked against the correct version of
the library.
See for example here:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
==== copy/paste ====
When a new version of a library is binary-incompatible with the old one
the soname needs to change. In C, there are four basic reasons that a
library would cease to be binary compatible:
1. The behavior of a function changes so that it no longer meets
its original specification,
2. Exported data items change (exception: adding optional items to
the ends of structures is okay, as long as those structures are
only allocated within the library).
3. An exported function is removed.
4. The interface of an exported function changes.
If you can avoid these reasons, you can keep your libraries
binary-compatible. Said another way, you can keep your Application
Binary Interface (ABI) compatible if you avoid such changes. For
example, you might want to add new functions but not delete the old
ones. You can add items to structures but only if you can make sure that
old programs won't be sensitive to such changes by adding items only to
the end of the structure, only allowing the library (and not the
application) to allocate the structure, making the extra items optional
(or having the library fill them in), and so on. Watch out - you
probably can't expand structures if users are using them in arrays.
==== copy/paste ====
By adding entries to the ipc, you are breaking ABI unless you are 100%
sure that an old version of cpg.lcrso will work just fine with the new
library and viceversa.
Fabio
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
