I agree with your view on iba/ib_types.h I'm not sure I understand what you mean in terms of libibumad. He's including libibmad rather than libibumad. So I suspect you mean changing this (ib_gid_t) to mad_gid_t ?
-- Hal ________________________________ From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] Sent: Mon 8/14/2006 3:44 PM To: [EMAIL PROTECTED] Cc: [email protected]; Hal Rosenstock Subject: Re: Conflicting typedefs for "ib_gid_t" Quoting r. [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Subject: Re: Conflicting typedefs for "ib_gid_t" > > > > > This is a similar but more mainstream example of the conflicts. A previous > > one was reported last week in terms of CM. Still not sure of the best > > resolution for this. > > > > Do you really need both includes ? > > > > The userspace tool shows a textual representation of a HCA port's capability > mask. So it requires the port capability bit definitions in ib_types.h. And I > require mad.h for the MAD API. I don't think the way forward is using iba/ in all applications. I see it mostly as a legacy header for opensm and related apps that want their own layer for portability between stacks. Wrt issue at hand, using ib_ prefix anywhere is a mistake which will always lead to conflicts between libraries. Let us start prefixing types libibumad defines with umad_, just like ib verbs library prefixes types by ibv_. For example we have union ibv_gid, so can't mad.h have umad_gid_t? Hal, what do you say? -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
