> Sean, what is intended for qp_state handling here? It seems > ib_copy_qp_attr_to_user() should either clear it or set it to something > sensible. I'm not sure what the original intent was, but both libibcm and librdmacm provide the qp_state as input to the init_qp_attr calls. It doesn't end up mattering if the kernel returns the value because the corresponding call in libibverbs (ibv_copy_qp_attr_from_kern) doesn't copy out the qp_state. So, the value that was originally specified ends up being used. The flow looks something like this: qp_attr.qp_state = INIT; cmd.qp_state = qp_attr.qp_state; write(..cmd..); ibv_copy_qp_attr_from_kern(&qp_attr, cmd.resp) I agree that it makes sense for ib_copy_qp_attr_to_user() to set the qp_state. Deciding what to do in libibverbs seems more troublesome. - Sean -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
