Re: [ewg] libibumad.so version bump in OFED 1.5.2
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
Re: [ewg] 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 content of link_layer file is used.
The libibumad version is promoted.
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
diff --git a/libibumad/include/infiniband/umad.h
b/libibumad/include/infiniband/umad.h
index 1f82183..f9da204 100644
--- a/libibumad/include/infiniband/umad.h
+++ b/libibumad/include/infiniband/umad.h
@@ -116,6 +116,7 @@ typedef struct ib_user_mad {
#define SYS_PORT_RATE rate
#define SYS_PORT_GUID port_guid
#define SYS_PORT_GID gids/0
+#define SYS_PORT_LINK_LAYERlink_layer
typedef struct umad_port {
char ca_name[UMAD_CA_NAME_LEN];
@@ -132,6 +133,7 @@ typedef struct umad_port {
uint64_t port_guid;
unsigned pkeys_size;
uint16_t *pkeys;
+ char link_layer[UMAD_CA_NAME_LEN];
} umad_port_t;
typedef struct umad_ca {
diff --git a/libibumad/libibumad.ver b/libibumad/libibumad.ver
index 57cddbd..d36fbbc 100644
--- a/libibumad/libibumad.ver
+++ b/libibumad/libibumad.ver
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=2:1:0
+LIBVERSION=2:2:0
diff --git a/libibumad/src/umad.c b/libibumad/src/umad.c
index 277ae6b..d16e750 100644
--- a/libibumad/src/umad.c
+++ b/libibumad/src/umad.c
@@ -159,6 +159,11 @@ static int get_port(char *ca_name, char *dir, int
portnum, umad_port_t * port)
if (sys_read_uint(port_dir, SYS_PORT_CAPMASK, port-capmask)
0)
goto clean;
+ 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);
+
port-capmask = htonl(port-capmask);
if (sys_read_gid(port_dir,
Re: [ewg] 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 content of link_layer file is used.
The libibumad version is promoted.
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
diff --git a/libibumad/include/infiniband/umad.h
b/libibumad/include/infiniband/umad.h
index 1f82183..f9da204 100644
--- a/libibumad/include/infiniband/umad.h
+++ b/libibumad/include/infiniband/umad.h
@@ -116,6 +116,7 @@ typedef struct ib_user_mad {
#define SYS_PORT_RATE rate
#define SYS_PORT_GUID port_guid
#define SYS_PORT_GID gids/0
+#define SYS_PORT_LINK_LAYERlink_layer
typedef struct umad_port {
char ca_name[UMAD_CA_NAME_LEN];
@@ -132,6 +133,7 @@ typedef struct umad_port {
uint64_t port_guid;
unsigned pkeys_size;
uint16_t *pkeys;
+ char link_layer[UMAD_CA_NAME_LEN];
} umad_port_t;
typedef struct umad_ca {
diff --git a/libibumad/libibumad.ver b/libibumad/libibumad.ver
index 57cddbd..d36fbbc 100644
--- a/libibumad/libibumad.ver
+++ b/libibumad/libibumad.ver
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=2:1:0
+LIBVERSION=2:2:0
diff --git a/libibumad/src/umad.c b/libibumad/src/umad.c
index 277ae6b..d16e750 100644
--- a/libibumad/src/umad.c
+++ b/libibumad/src/umad.c
@@ -159,6 +159,11 @@ static int get_port(char *ca_name, char *dir, int portnum,
umad_port_t * port)
if (sys_read_uint(port_dir, SYS_PORT_CAPMASK, port-capmask) 0)
goto clean;
+ 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);
+
port-capmask = htonl(port-capmask);
if (sys_read_gid(port_dir, SYS_PORT_GID, gid) 0)
Altering 'struct umad_port' effectively breaks ABI.
Sasha
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] libibumad.so version bump in OFED 1.5.2
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?)
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.
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.
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 content of link_layer file is used.
The libibumad version is promoted.
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
diff --git a/libibumad/include/infiniband/umad.h
b/libibumad/include/infiniband/umad.h
index 1f82183..f9da204 100644
--- a/libibumad/include/infiniband/umad.h
+++ b/libibumad/include/infiniband/umad.h
@@ -116,6 +116,7 @@ typedef struct ib_user_mad {
#define SYS_PORT_RATErate
#define SYS_PORT_GUIDport_guid
#define SYS_PORT_GID gids/0
+#define SYS_PORT_LINK_LAYER link_layer
typedef struct umad_port {
char ca_name[UMAD_CA_NAME_LEN];
@@ -132,6 +133,7 @@ typedef struct umad_port {
uint64_t port_guid;
unsigned pkeys_size;
uint16_t *pkeys;
+ char link_layer[UMAD_CA_NAME_LEN];
} umad_port_t;
typedef struct umad_ca {
diff --git a/libibumad/libibumad.ver b/libibumad/libibumad.ver
index 57cddbd..d36fbbc 100644
--- a/libibumad/libibumad.ver
+++ b/libibumad/libibumad.ver
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=2:1:0
+LIBVERSION=2:2:0
diff --git a/libibumad/src/umad.c b/libibumad/src/umad.c
index 277ae6b..d16e750 100644
--- a/libibumad/src/umad.c
+++ b/libibumad/src/umad.c
@@ -159,6 +159,11 @@ static int get_port(char *ca_name, char *dir, int
portnum, umad_port_t * port)
if (sys_read_uint(port_dir, SYS_PORT_CAPMASK, port-capmask)
0)
goto clean;
+ 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);
+
port-capmask = htonl(port-capmask);
if (sys_read_gid(port_dir, SYS_PORT_GID, gid) 0)
Altering 'struct umad_port' effectively breaks ABI.
Sasha
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] libibumad.so version bump in OFED 1.5.2
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. The ChangeLog simply says: ** Version: libibumad-1.3.4 Sun Dec 13 19:39:11 2009 +0200 Sasha Khapyorsky 2ebf19e61bb887b226017c0ac5a7f30ea0cd9e3f * management: package versions bump Sun Dec 13 19:36:19 2009 +0200 Sasha Khapyorsky b7f0e58ada74b4da01a39a9c5fd2f5517d70d26a * management: update library versions Tue Nov 17 14:39:37 2009 -0800 Ira Weiny f25da9f189638c1772d7c3cc5e1942b8d1e8abf8 * libibmad: libibumad: Print warnings and errors to stderr not stdout Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
