On Thu, 2009-08-20 at 15:53 +0200, Fabio M. Di Nitto wrote:
> On Thu, 2009-08-20 at 15:18 +0200, Jan Friesse wrote:
> > Fabio,
> > when will libtool happened? I would like to have this feature + tool in
> > Corosync 1.1.0.
>
> I don't know. I think Jim started on this conversion. If necessary I can
> take it over but it won't happen overnight.
>
> > Is attached patch good solution of problem?
>
> Unfortunately no because it will bump the soname for all libraries.
> That's why we need a more fine graded control over them with libtools.
>
> Fabio
>
cpg_iteration functionality is not gating on libtool. Honza, please
sort out a way to have finer version number control for the cpg library.
Regards
-steve
> >
> > Regards,
> > Honza
> >
> > Fabio M. Di Nitto napsal(a):
> > > 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
