There's a bug in ib_member_set_state, as it ends up OR-ing the existing state with the supplied state. Basically, it is masking the wrong bits before OR-ing in the state.
You could change ib_member_set_join_state to call ib_member_set_state. However, if the use of ib_member_set_state always has the caller passing the join_state field of an member record structure, then it should just be eliminated and ib_member_set_join_state used instead. -Fab From: [email protected] [mailto:[email protected]] On Behalf Of Tzachi Dar Sent: Tuesday, September 27, 2011 12:19 PM To: [email protected]; Hal Rosenstock Subject: [ofw] wrong usage of ib_member_set_state on windows we have the following 3 functions: AL_INLINE void AL_API ib_member_set_state( IN OUT uint8_t* const p_scope_state, IN const uint8_t state ) { CL_ASSERT( state <= 0x0F ); /* State is LS 4-bits. */ *p_scope_state &= 0x0F; *p_scope_state |= (state & 0x0F); } AL_INLINE void AL_API ib_member_set_join_state( IN OUT ib_member_rec_t *p_mc_rec, IN const uint8_t state ) { p_mc_rec->scope_state &= 0xF0; p_mc_rec->scope_state |= (state & 0x0F); } AL_INLINE uint8_t AL_API ib_member_set_scope_state( IN const uint8_t scope, IN const uint8_t state ) { /* Scope is MS 4-bits, state is LS 4-bits */ return ((scope << 4) | (state & 0xF)); } Ipoib is using ib_member_set_state(). As far as I can tell this will cause the scope to be zero (on table 3, the value of 0 is reserved). Is this what we relay wanted to have? Thanks Tzachi
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
