Sean, You proposed here another solution for __ptr64 problem, and we discussed its profs and cons before (please, see my first post on this topic)
But this proposal is not relevant to my patch at all. It is relevant. The TO_LONG_PTR and NULL_PTR64 macros, which your patch touches, are a direct result of the __ptr64 'solution'. Just look at the resulting code that we now have. It's a mess: + wr = (struct _wr * VOID_PTR64)HDL_TO_PTR(wc->wr_id); + p_recv_wr = (struct _recv_wr * VOID_PTR64)HDL_TO_PTR(wc->wr_id); - cb_info.ioctl_rec.event_rec.handle.h_ca = (ib_ca_handle_t VOID_PTR64)h_ca->obj.hdl; + cb_info.ioctl_rec.event_rec.handle.h_ca = (ib_ca_handle_t VOID_PTR64)HDL_TO_PTR(h_ca->obj.hdl); + cb_info.ioctl_rec.event_rec.handle.h_srq = (ib_srq_handle_t VOID_PTR64) HDL_TO_PTR(h_srq->obj.hdl); + cb_info.ioctl_rec.event_rec.handle.h_qp = (ib_qp_handle_t VOID_PTR64)HDL_TO_PTR(h_qp->obj.hdl); yada yada yada The only thing we're achieving is code obscurity. - Sean
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
