[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