>I am fine with the approach of always report the event and let ULPs >ignore it. Looking on how the ABI versions are exchanged between the >rdma_ucm module to librdmacm, I don't see much alternatives other to >bumping the ABI version to five. If librdmacm can somehow note against >what ABI version the app was built, we could bump the ABI version to >five and require the user to upgrade his librdmacm to be able to run, >but have --librdmacm-- hide this event from the user in case "his >version" of the ABI is smaller.
I was only thinking of the kernel interfaces, but I don't see that this really changes the ABI. An existing library continues to work unmodified. (Is this that different than adding a new return value from a call?) If there really is an issue, then the rdma_ucm can toss the event. >I would like to look into this possibility which as you stated later in >your post is simpler compared to the alternatives and would also make >the current code of supporting device removal less complex. So >can/should that mutex be the existing one defined in cma.c or a new one? After more thought, this approach is what I would try first. I think you will need a new mutex per rdma_cm_id that does nothing but serializes callbacks. You might be able to acquire/release it in disable/enable remove, but I didn't look into the implementation in that much detail. - Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
