On Tue, Mar 14, 2017 at 05:14:55PM +0200, Yishai Hadas wrote: > It's not an issue of 'basic' and 'complex' API but a question of code > sharing and resource managing. This can always be acheived with some code restructuring. eg we can put the tail of __lib_ibv_create_cq_ex into a helper, or have an internal create_cq that accepts the void *provider_data There is a lot less code inside libibverbs that outside, I'd rather have an obvious clean user API than make our lives a tiny bit easier. > >>Once the correct structure is used there should be *no* safety > >>issue, please note that the vendor data defined to be as some > >>extended structure which can only be grown based on comp_mask so > >>that compatibility will be saved in any case. > > > >No, you still have to make sure that your ib_device is somehow a mlx5. > > We are talking on an application that previously read some vendor > capabilities using a direct API (e.g. mlx5dv_query_device) to know whether > the vendor functionality is supported. With these patches if the app passes the wrong thing into the vendor_data it crashes, with a mlx5_create_cq it would get an error code. Error codes are better. Yishai, even if we go this way, stop using the word 'vendor'. It is not vendor data. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
