[openib-general] umad abi 2 v 3 and multicast join failed

[Hal Rosenstock]

On Thu, 2005-05-26 at 00:07, Roland Dreier wrote:
>     Troy> warn: [24878] umad_init: wrong ABI version:
>     Troy> /sys/class/infiniband_mad/abi_version is 2 but library ABI
>     Troy> is 3
> 
>     Hal> Right. This is old OpenSM (actually old libibumad) with the
>     Hal> latest from OpenIB svn (past where I put the changes to
>     Hal> support send side RMPP in).
> 
> Are you sure?  The kernel seems to be reporting an older ABI version
> than the library is looking for.

Then maybe I got it backwards. The email said that the OpenSM from
roland-uverbs branch was being used which has to be the older ABI
version. The fact that the library version is 3 indicates to me that the
OpenSM being run is from the trunk.

> In general, given that kernels 2.6.11 and 2.6.12 are shipping with ABI
> version 2,

also we know there is some 2.6.9 backport work. I'm not sure which ABI
version this is using but if this is kept up to date, it will transition
to the newer one. So the old ABI version is a current issue for
2.6.11/12 relative to the current trunk for userspace/management.

>  does it make sense to avoid problems like this by keeping
> the old userspace code around and having the library decide at runtime
> which ABI to use?

It would be more than this to make it run time selectable as the API
changes filter back into the userspace applications.

Are there any examples of this elsewhere to look at ?

Would a branch suffice for this (old ABI version) ?

Would the older ABI version need to accomodate any OpenSM and diags
development that might be applicable to it ?

Any idea on how long the old ABI will need supporting ?

What is the general rule on older ABI support ? Is there a limit on how
many are supported and how long the older ABIs are supported ? Is this
just based on the needs of the community ?

These are questions I think need answering before deciding which way to
go on this.

-- Hal