>> * Move struct ib_sa_client definition internal to SA module to >> better encapsulate future extensions. > >Documentation/stable_api_nonsense.txt says: >"You think you want a stable kernel interface, but you really do not"
Encapsulation is typically a good idea. The user cannot modify anything inside of struct ib_sa_client without breaking it. The only benefit we gain by exposing it is saving a memory allocation. The verb interfaces expose the structures to allow for direct calls from a ULP to a provider for speed path operations. >Why is > ipoib_sa_client = ib_sa_register_client > ret = PTR_ERR(ipoib_sa_client) >a better encapsulation than > ret = ib_sa_register_client(&ipoib_sa_client) The former completely hides the internal definition of the structure from the user. The latter does not, providing no encapsulation. >Further, why should this API be different from ib_register_client? >Isn't this confusing? It's different from ib_register_client, but more similar to ib_register_mad_agent. If anything it would make more sense to be closer to ib_register_mad_agent. For example, a callback function makes more sense passed into a register call than every query call. >Isn't it better to let user control where does the memory come from, >rather than forcing GFP_KERNEL? The sa_query module _is_ the user of the memory, but can add a gfp_mask if we think that's useful. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
