Re: [PATCH] libibmad: To fix big endian problem for both 32-bit & 64-bit SPARC

[Boris Chiu <boris.chiu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

Hi Hal and Or,

We are checking on this and will get back.

Thanks,
Boris

On 03/13/13 05:58, Or Gerlitz wrote:
> On 13/03/2013 14:48, Hal Rosenstock wrote:
>> On 3/12/2013 3:36 PM, Boris Chiu wrote:
>>> >--- a/src/dump.c
>>> >+++ b/src/dump.c
>>> >@@ -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 */
>> 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.
>
>
>
>>
>> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html