[PATCH] libibmad: Fix conflict with new umad.h header

[PATCH] libibmad: Fix conflict with new umad.h header

[ira.weiny-ral2JQCrhuEAvxtiuMwx3w]

From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Signed-off-by: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/mad.h | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/include/infiniband/mad.h b/include/infiniband/mad.h
index 77858c3fe6e1..2911dee3cdf4 100644
--- a/include/infiniband/mad.h
+++ b/include/infiniband/mad.h
@@ -1662,29 +1662,17 @@ extern MAD_EXPORT int ibdebug;
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #ifndef ntohll
-static inline uint64_t ntohll(uint64_t x)
-{
-	return bswap_64(x);
-}
+#define ntohll bswap_64
 #endif
 #ifndef htonll
-static inline uint64_t htonll(uint64_t x)
-{
-	return bswap_64(x);
-}
+#define htonll bswap_64
 #endif
 #elif __BYTE_ORDER == __BIG_ENDIAN
 #ifndef ntohll
-static inline uint64_t ntohll(uint64_t x)
-{
-	return x;
-}
+#define ntohll(x) x
 #endif
 #ifndef htonll
-static inline uint64_t htonll(uint64_t x)
-{
-	return x;
-}
+#define htonll(x) x
 #endif
 #endif				/* __BYTE_ORDER == __BIG_ENDIAN */
 
-- 
1.8.2.3

--
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

Re: [PATCH] libibmad: Fix conflict with new umad.h header

[Jason Gunthorpe]

On Fri, Feb 24, 2017 at 12:40:27AM -0500, ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Bleck, how did this ever work sanely like this??

This is the version you should copy:

#ifndef ntohll
#undef htonll
#undef ntohll
/* Users should use the glibc functions directly, not these wrappers */
static inline __attribute__((deprecated)) uint64_t htonll(uint64_t x) { return htobe64(x); }
static inline __attribute__((deprecated)) uint64_t ntohll(uint64_t x) { return be64toh(x); }
#define htonll htonll
#define ntohll ntohll
#endif

> +#define ntohll(x) x

missing () around the x.

Jason
--
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

RE: [PATCH] libibmad: Fix conflict with new umad.h header

[Weiny, Ira]

> On Fri, Feb 24, 2017 at 12:40:27AM -0500, ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> > From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Bleck, how did this ever work sanely like this??

I don't know...

Libibmad should have been combined into infinband-diags years ago...  I just never seem to have the time...

> 
> This is the version you should copy:
> 
> #ifndef ntohll
> #undef htonll
> #undef ntohll
> /* Users should use the glibc functions directly, not these wrappers */ static
> inline __attribute__((deprecated)) uint64_t htonll(uint64_t x) { return
> htobe64(x); } static inline __attribute__((deprecated)) uint64_t ntohll(uint64_t
> x) { return be64toh(x); } #define htonll htonll #define ntohll ntohll #endif

Perhaps...

The question is do you want to rely on BSD or gnu extensions?  My reading of the various man pages leads me to the same path as you.  That the BSD htobe* has become the standard in glibc.

However, anyone currently using libibmad must have bswap_*.  Therefore this will not break them.

> 
> > +#define ntohll(x) x
> 
> missing () around the x.

Yea missed that...

Thanks,
Ira

> 
> Jason
--
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

Re: [PATCH] libibmad: Fix conflict with new umad.h header

[Jason Gunthorpe]

On Fri, Feb 24, 2017 at 09:23:26PM +0000, Weiny, Ira wrote:
> 
> Perhaps...
> 
> The question is do you want to rely on BSD or gnu extensions?  My
> reading of the various man pages leads me to the same path as you.
> That the BSD htobe* has become the standard in glibc.

If you go down that rat hole then __BYTE_ORDER__ isn't portable
either..

Which ever you choose, both places should use an identical construct,
introducing two different definitions is evil.

bswap_64 is a tiny bit better because it does not rely on __USE_MISC
which means the public header might compile with -std=c11/-ansi/etc

However I did a little check and some of our public headers already do
not support that mode...

So my conclusion was to go with the simple solution, and mark it
deprecated so we can remove it some day and avoid this worry.

I guess it could get wrappered in '#ifdef htobe64' though - then it
would still support -ansi mode.

> > > +#define ntohll(x) x
> > 
> > missing () around the x.
> 
> Yea missed that...

It is also problematic in that it doesn't force the output to a
consistent 64 bit type, so big/little builds get different types which
is never fun.

Jason
--
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