[ofa-general] Re: Dapl 2 question/issue

[Doug Ledford]

On Tue, 2008-01-29 at 19:39 +0000, Tang, Changqing wrote:
> 
> > A runtime dlopen is different than being linked against a
> > library, and yes in this case you would now have to
> > dlopen(libdat2.so) and if that fails fall back to
> > (libdat.so).  However, given that according to the
> > dapl-1 to dapl-2 porting guide there are several structures
> > that have changed their layout between dat-1 and dat-2, I
> > would think that HP-MPI would have to jump through hoops
> > (either by knowing about both layouts, or by knowing what
> > structures to avoid because they change) in order to support
> > working with either dat-1 or dat-2 at runtime.  If anything,
> > that would make me think this is a good example of why they
> > *should* be different library names.
> 
> If there is a way to seamlessl work on either version available on the system
> without asking user for choice, I am OK to change the library name.

I don't think there is.  Dapl-1 and dapl-2 simply are not API
compatible.  You have to port to dapl-2 (or so the docs say, I haven't
written any code that uses dapl, so I can't speak from experience).

> According what you said, we can dlopen(libdat2.so) first, then fallback to
> dlopen(libdat.so).
> 
> But we have to claim that HP-MPI xxx version and older does not work with
> uDAPL 2.0.

You *should* be claiming that regardless.  The API between dapl-1 and
dapl-2 changed, some of which is fixed simply be recompiling and some of
which requires actual code changes.  Just because the library name is
the same doesn't mean that code built and compiled against dapl-1 could
or should attempt to run against dapl-2 (unless I'm wrong here, Arlin
should really speak to this issue...if the dapl-2 libraries provide
backward compatible symbols via so symbol versions, then it might be
possible for a dapl-1 program to run against the dapl-2 library, but
then that would beg the question of why we are still distributing dapl-1
libraries in a separate package, so I'm guessing there is not a back
compatible layer in the dapl-2 library).

>  Currently HP-MPI works seamlessly on uDAPL 1.1 or uDAPL 1.2 system.

Yes, and that's typical.  Between minor point releases it's common that
things "just work".  Between major releases, it isn't.  Between major
releases it's common that at a minimum a recompile and relink is needed,
but in this case you not only need a recompile and relink, but you need
a few logical changes as well.  It isn't plug-n-play for the dapl-1 to
dapl-2 update.

> 
> --CQ
> 
> 
> > > --CQ
> > >
> > >
> > >
> > > >
> > > > -arlin
> > > >
> > > >
> > > > _______________________________________________
> > > > general mailing list
> > > > general at lists.openfabrics.org
> > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > > >
> > > > To unsubscribe, please visit
> > > > http://openib.org/mailman/listinfo/openib-general
> > > >
> > --
> > Doug Ledford <dledford at redhat.com>
> >               GPG KeyID: CFBFF194
> >               http://people.redhat.com/dledford
> >
> > Infiniband specific RPMs available at
> >               http://people.redhat.com/dledford/Infiniband
> >
-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080129/17d267ec/attachment.sig>