Skip to contentSkip to conversation

libibmad: To fix big endian problem for both 32-bit & 64-bit SPARC

PATCH In review Boris Chiu 5 participants 7 messages Mar 12, 2013 – Apr 18, 2013 5 messages not in the archive InfiniBand

lore
Share & tools
lore

Boris Chiu

author
#0 lore raw

PATCH 1/1 libibmad: To fix big endian problem for both 32-bit & 64-bit SPARC

From: Brendan Doyle <[email protected]>

Signed-off-by Brendan Doyle <[email protected]>

---
src/dump.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++--------

1 files changed, 57 insertions(+), 9 deletions(-)
src/dump.c +0 -0
index 7f3ef7d..e83c363 100644
@@ -46,12 +46,24 @@

void mad_dump_int(char *buf, int bufsz, void *val, int valsz) {
+ /*
+ * the val pointer passed to the dump routines are always 32 bit
+ * integers for valsz <= 4 and 64 bit integer for the rest. It is never
+ * uint8_t or uint16_t. This is because mad_decode_field always returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit fields.
+ */

	switch (valsz) {
	case 1:

- snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%d", *(uint8_t *) val & 0xff);
		break;
	case 2:

- snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%d", *(uint16_t *) val & 0xffff);
		break;
	case 3:
	case 4:

@@ -71,12 +83,24 @@ void mad_dump_int(char *buf, int bufsz, void *val, int valsz)

void mad_dump_uint(char *buf, int bufsz, void *val, int valsz) {
+ /*
+ * the val pointer passed to the dump routines are always 32 bit
+ * integers for valsz <= 4 and 64 bit integer for the rest. It is never
+ * uint8_t or uint16_t. This is because mad_decode_field always returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit fields.
+ */

	switch (valsz) {
	case 1:

- snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%u", *(uint8_t *) val & 0xff);
		break;
	case 2:

- snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%u", *(uint16_t *) val & 0xffff);
		break;
	case 3:
	case 4:

@@ -96,15 +120,27 @@ void mad_dump_uint(char *buf, int bufsz, void *val, int valsz)

void mad_dump_hex(char *buf, int bufsz, void *val, int valsz) {
+ /*
+ * the val pointer passed to the dump routines are always 32 bit
+ * integers for valsz <= 4 and 64 bit integer for the rest. It is never
+ * uint8_t or uint16_t. This is because mad_decode_field always returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit fields.
+ */

	switch (valsz) {
	case 1:

- snprintf(buf, bufsz, "0x%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "0x%02x", *(uint8_t *) val & 0xff);
		break;
	case 2:

- snprintf(buf, bufsz, "0x%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "0x%04x", *(uint16_t *) val & 0xffff);
		break;
	case 3:
-		snprintf(buf, bufsz, "0x%06x", *(uint32_t *) val & 0xffffff);
+		snprintf(buf, bufsz, "0x%x", *(uint32_t *) val & 0xffffff);
		break;
	case 4:
		snprintf(buf, bufsz, "0x%08x", *(uint32_t *) val);

@@ -132,12 +168,24 @@ void mad_dump_hex(char *buf, int bufsz, void *val, int valsz)

void mad_dump_rhex(char *buf, int bufsz, void *val, int valsz) {
+ /*
+ * the val pointer passed to the dump routines are always 32 bit
+ * integers for valsz <= 4 and 64 bit integer for the rest. It is never
+ * uint8_t or uint16_t. This is because mad_decode_field always returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit fields.
+ */

	switch (valsz) {
	case 1:

- snprintf(buf, bufsz, "%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%02x", *(uint8_t *) val & 0xff);
		break;
	case 2:

- snprintf(buf, bufsz, "%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+ val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */

+		snprintf(buf, bufsz, "%04x", *(uint16_t *) val & 0xffff);
		break;
	case 3:
		snprintf(buf, bufsz, "%06x", *(uint32_t *) val & 0xffffff);
Signature · 7 lines
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#2 lore raw
In reply to a message not in the archive
Quoted 24 lines · Boris Chiu

From: Brendan Doyle <[email protected]>

Signed-off-by Brendan Doyle <[email protected]>

---
src/dump.c | 66
+++++++++++++++++++++++++++++++++++++++++++++++++++--------

1 files changed, 57 insertions(+), 9 deletions(-)
src/dump.c +3 -0
index 7f3ef7d..e83c363 100644
@@ -46,12 +46,24 @@
 
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c

Quoted 7 lines
src/dump.c +4 -1
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

At a minimum, should this be ifdef'd on something like both __sun and __SVR4 rather than _BIG_ENDIAN ?

-- Hal

Quoted 98 lines
src/dump.c +8 -1
+        snprintf(buf, bufsz, "%d", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%d", *(uint16_t *) val & 0xffff);
        break;
    case 3:
    case 4:

@@ -71,12 +83,24 @@ void mad_dump_int(char *buf, int bufsz, void *val,
 int valsz)
 
 void mad_dump_uint(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +12 -2
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%u", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%u", *(uint16_t *) val & 0xffff);
        break;
    case 3:
    case 4:

@@ -96,15 +120,27 @@ void mad_dump_uint(char *buf, int bufsz, void *val,
 int valsz)
 
 void mad_dump_hex(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +13 -3
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "0x%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "0x%02x", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "0x%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "0x%04x", *(uint16_t *) val & 0xffff);
        break;
    case 3:
-        snprintf(buf, bufsz, "0x%06x", *(uint32_t *) val & 0xffffff);
+        snprintf(buf, bufsz, "0x%x", *(uint32_t *) val & 0xffffff);
        break;
    case 4:
        snprintf(buf, bufsz, "0x%08x", *(uint32_t *) val);

@@ -132,12 +168,24 @@ void mad_dump_hex(char *buf, int bufsz, void *val,
 int valsz)
 
 void mad_dump_rhex(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +5 -1
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%02x", *(uint8_t *) val & 0xff);

src/dump.c

Quoted 10 lines
src/dump.c +4 -1
        break;
    case 2:
-        snprintf(buf, bufsz, "%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%04x", *(uint16_t *) val & 0xffff);
        break;
    case 3:
        snprintf(buf, bufsz, "%06x", *(uint32_t *) val & 0xffffff);

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to a message not in the archive
Quoted 16 lines · Hal Rosenstock
Quoted 15 lines · Boris Chiu
Quoted 15 lines
src/dump.c +3 -0
@@ -46,12 +46,24 @@
 
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.
+ */

Quoted 8 lines
Quoted 6 lines

src/dump.c

Quoted 6 lines
    switch (valsz) {
    case 1:
src/dump.c +3 -1
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

Yep, agree, assuming the code works on other BE archs, we 1st and most need to understand the problem before going to solutions.

Or.

Quoted 3 lines

At a minimum, should this be ifdef'd on something like both __sun and __SVR4 rather than _BIG_ENDIAN ?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#11 lore raw
In reply to a message not in the archive
Quoted 44 lines

-----Original Message-----
From: [email protected] [mailto:linux-rdma- [email protected]] On Behalf Of Hal Rosenstock
Sent: Wednesday, March 13, 2013 8:48 AM
To: Boris Chiu
Cc: Ira Weiny; [email protected]
Subject: Re: [PATCH] libibmad: To fix big endian problem for both 32-bit & 64- bit SPARC

Quoted 23 lines · Boris Chiu

From: Brendan Doyle <[email protected]>

Signed-off-by Brendan Doyle <[email protected]>

---
src/dump.c | 66
+++++++++++++++++++++++++++++++++++++++++++++++++++--------

1 files changed, 57 insertions(+), 9 deletions(-)
src/dump.c +3 -0
index 7f3ef7d..e83c363 100644
@@ -46,12 +46,24 @@
 
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz) {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c

Quoted 7 lines
src/dump.c +4 -1
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

Quoted 2 lines

At a minimum, should this be ifdef'd on something like both __sun and __SVR4 rather than _BIG_ENDIAN ?

Are you perhaps calling these with Network Byte order values? While not documented they are designed to take values in host byte order which as Hal states should work on all big and little endian architectures.

Ira

Quoted 105 lines

-- Hal

Quoted 102 lines
src/dump.c +8 -1
+        snprintf(buf, bufsz, "%d", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%d", *(uint16_t *) val & 0xffff);
        break;
    case 3:
    case 4:

@@ -71,12 +83,24 @@ void mad_dump_int(char *buf, int bufsz, void *val,
 int valsz)
 
 void mad_dump_uint(char *buf, int bufsz, void *val, int valsz) {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +12 -2
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%u", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "%u", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%u", *(uint16_t *) val & 0xffff);
        break;
    case 3:
    case 4:

@@ -96,15 +120,27 @@ void mad_dump_uint(char *buf, int bufsz, void
 *val, int valsz)
 
 void mad_dump_hex(char *buf, int bufsz, void *val, int valsz) {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +11 -3
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "0x%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "0x%02x", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "0x%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "0x%04x", *(uint16_t *) val & 0xffff);
        break;
    case 3:
-        snprintf(buf, bufsz, "0x%06x", *(uint32_t *) val & 0xffffff);
+        snprintf(buf, bufsz, "0x%x", *(uint32_t *) val & 0xffffff);
        break;
    case 4:
        snprintf(buf, bufsz, "0x%08x", *(uint32_t *) val); @@ -132,12
+168,24 @@ void mad_dump_hex(char *buf, int bufsz, void *val, int

valsz)

void mad_dump_rhex(char *buf, int bufsz, void *val, int valsz) {

src/dump.c +3 -0
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.

src/dump.c +9 -2
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%02x", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%02x", *(uint8_t *) val & 0xff);
        break;
    case 2:
-        snprintf(buf, bufsz, "%04x", *(uint32_t *) val & 0xffff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint16_t *)val) + 1;
+#endif /* _BIG_ENDIAN */
+        snprintf(buf, bufsz, "%04x", *(uint16_t *) val & 0xffff);
Quoted 8 lines
Quoted 3 lines
        break;
    case 3:
        snprintf(buf, bufsz, "%06x", *(uint32_t *) val & 0xffffff);

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#6 lore raw
In reply to a message not in the archive

Hi Hal and Or,

We are checking on this and will get back.

Thanks,
Boris

Quoted 26 lines · Or Gerlitz
Quoted 16 lines · Hal Rosenstock
Quoted 15 lines · Boris Chiu
Quoted 15 lines
src/dump.c +3 -0
@@ -46,12 +46,24 @@
 
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest. It is

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit
fields.
+ */

Quoted 8 lines
Quoted 6 lines

src/dump.c

Quoted 6 lines
    switch (valsz) {
    case 1:
src/dump.c +3 -1
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

Quoted 10 lines

Yep, agree, assuming the code works on other BE archs, we 1st and most need to understand the problem before going to solutions.

Or.

Quoted 3 lines

At a minimum, should this be ifdef'd on something like both __sun and __SVR4 rather than _BIG_ENDIAN ?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw
In reply to a message not in the archive

Hello Hal / Or,

Sorry for the delay in getting back on this.

Solaris specific endian fixes were applied to OFED 1.3 in order to
fix infiniband-diag failures observed
on SPARC. Changes to OFED 1.5.3 now make these fixes redundant
consequently the patch request
is withdrawn.

Let us know if you have any queries.

Thanks
Pramod

Quoted 37 lines

Hi Hal and Or,

We are checking on this and will get back.

Thanks,
Boris

Quoted 29 lines · Or Gerlitz
Quoted 11 lines · Hal Rosenstock
Quoted 10 lines · Boris Chiu

src/dump.c line 51

Quoted 9 lines
src/dump.c +3 -0
@@ -46,12 +46,24 @@
 
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz)
 {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest.

It is

Quoted 14 lines
Quoted 4 lines
Quoted 4 lines

never
+ * uint8_t or uint16_t. This is because mad_decode_field always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16 bit

Quoted 8 lines

src/dump.c

Quoted 8 lines

fields.

src/dump.c +4 -1
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3;
+#endif /* _BIG_ENDIAN */

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

Yep, agree, assuming the code works on other BE archs, we 1st and most need to understand the problem before going to solutions.

Quoted 12 lines
Quoted 8 lines

Or.

Quoted 3 lines

At a minimum, should this be ifdef'd on something like both __sun and __SVR4 rather than _BIG_ENDIAN ?

Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#10 lore raw
In reply to a message not in the archive

I'll reject the patch. Thanks for getting back to me.

Ira

Quoted 74 lines

-----Original Message-----
From: [email protected] [mailto:linux-rdma- [email protected]] On Behalf Of Pramod Gunjikar
Sent: Thursday, April 18, 2013 3:29 AM
To: Boris Chiu
Cc: Or Gerlitz; Hal Rosenstock; Ira Weiny; [email protected]
Subject: Re: [PATCH] libibmad: To fix big endian problem for both 32-bit & 64- bit SPARC

Hello Hal / Or,

Sorry for the delay in getting back on this.

Solaris specific endian fixes were applied to OFED 1.3 in order to fix
infiniband-diag failures observed
on SPARC. Changes to OFED 1.5.3 now make these fixes redundant
consequently the patch request
is withdrawn.

Let us know if you have any queries.

Thanks
Pramod

Quoted 43 lines

Hi Hal and Or,

We are checking on this and will get back.

Thanks,
Boris

Quoted 35 lines · Or Gerlitz
Quoted 23 lines · Hal Rosenstock
Quoted 4 lines · Boris Chiu
Quoted 4 lines
src/dump.c +0 -0
@@ -46,12 +46,24 @@
Quoted 18 lines

src/dump.c line 50

Quoted 4 lines
src/dump.c +3 -0
 void mad_dump_int(char *buf, int bufsz, void *val, int valsz) {
+    /*
+     * the val pointer passed to the dump routines are always 32 bit
+     * integers for valsz <= 4 and 64 bit integer for the rest.

It is

Quoted 13 lines

never
+ * uint8_t or uint16_t. This is because mad_decode_field
+ always
returns
+ * the values as 32 bit integer even if they are 8 bit or 16
+ bit
fields.

src/dump.c +3 -1
+     */
    switch (valsz) {
    case 1:
-        snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
+#if defined(_BIG_ENDIAN)
+        val = ((uint8_t *)val) + 3; #endif /* _BIG_ENDIAN */
Quoted 2 lines

I don't understand what's different about SPARC and PPC in terms of this. These routines all work without this on PPC64 and PPC32.

Yep, agree, assuming the code works on other BE archs, we 1st and most need to understand the problem before going to solutions.

Or.

Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines

At a minimum, should this be ifdef'd on something like both __sun and
__SVR4 rather than _BIG_ENDIAN ?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More

Quoted 7 lines

majordomo

Quoted 1 line

info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html