> 1) On ib_join_mcast( ..., ib_mcast_handle_t *h_mcast); the h_mcast gets > back to the user from the call back. > I guess that there is no problem to return the h_mcast in the call itself > but are we sure this has a good reason?
This allows the user to cancel the join operation without destroying everything by closing their al instance. For example, after issuing a join, they can immediately respond to an SM change, reregister, or other event by freeing the join and issuing a new one. Without this, handling those events becomes more difficult. Hmm... on the Linux side, the multicast module reports those types of events against the join request. The user can receive multiple (serialized) callbacks for a single join call. How does ibal handle errors on a multicast group after a successful join? > 2) " Personally, I'm fine requiring the caller to handle the cleanup > (provided the kernel cleans up after user space)." > Doesn't this has an influence on the API which would actually force us to > have something else in the API (for example h_al) or something similar. Not necessarily. The user to kernel proxy code needs to associate the h_mcast with another object, such as the file, but that doesn't have to be in the kernel API. The proxy code must free the multicast object when the file is closed. You can look at the winverbs kernel cleanup code as an example. - Sean _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
