[openib-general] [libibcm] compilation of code that uses libibcm may fail
Michael S. Tsirkin
mst at mellanox.co.il
Tue Aug 8 12:30:08 PDT 2006
Quoting r. Hal Rosenstock <halr at voltaire.com>:
> Subject: Re: [libibcm] compilation of code that uses libibcm may fail
>
> On Mon, 2006-08-07 at 14:02, Sean Hefty wrote:
> > Dotan Barak wrote:
> > > enum ib_cm_sidr_status { 0, 1, 2, 3, 4, IB_SIDR_UNSUPPORTED_VERSION };
> > >
> > > it seems that the enumerations values were replaced with integers.
> > > when i searched for the values that were enumerated in the headre files i
> > > found the following defines in ib_types.h:
> > >
> > > #define IB_SIDR_SUCCESS 0 #define
> > > IB_SIDR_UNSUPPORTED 1 #define
> > > IB_SIDR_REJECT 2 #define
> > > IB_SIDR_NO_QP 3 #define
> > > IB_SIDR_REDIRECT 4
> > >
> > >
> > > I think that the problem was that ib_types.h was included in a file that
> > > includes the cm.h and the preprocessor replaced the enumeration names with
> > > the integer values.
> > >
> > > who can check this issue?
> >
> > I think the solution is to remove CM definitions out of ib_types.h.
>
> Perhaps.
Ugh.
Guys, how about we start adding proper library prefixes to names?
IBA really should name things IBA_..., CM should be CM_.. or IB_CM_...
If everyone insists on polluting the IB_ namespace conflicts are unavoidable.
With respect to API - this should not be a problem:
if there are some legacy applications it is easy to make ib_types.h
a wrapper header for these. Mark this stuff deprecated and make sure
no internal code uses them.
--
MST
More information about the general
mailing list