Is there a way to accomplish this feature without an ABI change? Or
should ABI altering features be only included in Major releases (such
as OFED 1.6?)
I urged about ABI change on the list when this patch was posted. And I don't
think that we can change the version back.
Since 1.5.2 is not yet GA, we always have the option of altering this patch and
moving the version back.
It sounds like you too were concerned about this when the change went in, I
suspect those on the list missed the ramifications to end users and ISVs of ABI
changes during maintenance releases. A situation like this will leave many
ISVs unable to support OFED 1.5.2.
We've already seen that situation with OFED 1.4 - 1.5. The various API and
ABI changes impacted many ISVs, so there are still some ISVs which are stuck on
OFED 1.4 and have not yet released OFED 1.5 support. This of course is causing
issues for customers which need OFED 1.5 features (such as newer kernel levels)
but require a given ISV's software.
Let's not repeat that same mistake for OFED 1.5.1 - 1.5.2.
In contrast, other aspects of linux provide forward migration. For example I
can generally build a binary on RHEL4 and run it on RHEL5. I can certainly
build files on RHEL5.0 and run them on RHEL5.5. Heck, I've got quite a few
tools whose binaries were built on even earlier redhat versions and still work
fine on RHEL5.5. OFED applications should be no different.
Todd Rimmer
Chief Architect
QLogic Network Systems Group
Voice: 610-233-4852 Fax: 610-233-4777
todd.rim...@qlogic.com www.QLogic.com
-Original Message-
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha
Khapyorsky
Sent: Tuesday, July 13, 2010 11:34 AM
To: Todd Rimmer
Cc: e...@openfabrics.org; Yevgeny Kliteynik; Tziporet Koren
Subject: Re: libibumad.so version bump in OFED 1.5.2
On 12:58 Wed 07 Jul , Todd Rimmer wrote:
Is there a way to accomplish this feature without an ABI change? Or
should ABI altering features be only included in Major releases (such
as OFED 1.6?)
I urged about ABI change on the list when this patch was posted. And I
don't think that we can change the version back.
Keep in mind, that ABI changes mean that 3rd parties must rebuild and
re-release their applications. While this isn't so bad for OFED itself
and IB vendors, it's a major issue for other 3rd party apps.
Introducing a ABI change in a maintenance release just makes things
that much more confusing.
One alternative would be for OFED 1.5.2 to include both the .2 and .3
versions of the library.
We discussed such option - to have a package compat-libs or so, but as
far as I can remember no one wanted to take responsibility to maintain
this.
Another alternative would be to design the structures so there is
room for expansion or pointers to opaque datatypes for fields only used
by the library.
Currently it would mean API redesign and more version changes.
Sasha
Todd Rimmer
Chief Architect
QLogic Network Systems Group
Voice: 610-233-4852 Fax: 610-233-4777
todd.rim...@qlogic.com www.QLogic.com
-Original Message-
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of
Sasha
Khapyorsky
Sent: Wednesday, July 07, 2010 9:34 AM
To: Todd Rimmer
Cc: e...@openfabrics.org
Subject: Re: libibumad.so version bump in OFED 1.5.2
Hi Todd,
On 06:48 Tue 06 Jul , Todd Rimmer wrote:
I recently discovered that 3rd party applications built for OFED
1.5
will not run on OFED 1.5.2rc2.
The issue I found was that libibumad had changed from version 2
to
version 3. Can you provide insight as to why this change was made?
In reviewing the source code and change logs there do not seem to
be
any changes which would impact the application API nor application
ABI.
I diffed the code and the main change seems to be:
diff -r --exclude CVS ./src/src/umad.c-orig ./src/src/umad.c
161a162,166
if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER,
port-link_layer, UMAD_CA_NAME_LEN) 0)
/* assume IB by default */
sprintf(port-link_layer, IB);
The above change might imply an update to an rpm dependency on
ib-
kernel versions, but should not result in a new library version.
If
the library version remained at 2, then applications built for OFED
1.5
would also run on OFED 1.5.2rc2 without recompile.
This is not an only change. The whole commit is:
commit 99d0901f3702e22c178352524af18ec567781d51
Author: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Date: Tue Mar 9 12:39:40 2010 +0200
libibumad: added link_layer for RoCEE support and updated umad
version
Added link_layer field to umad_port_t.
The field is implemented as char[].
If the relevant file doesn't exist in sysfs, the link layer
is IB. Otherwise, the
