On 21/07/2016 19:49, Jason Gunthorpe wrote:
On Thu, Jul 21, 2016 at 02:38:28PM +0300, Matan Barak wrote:
On 20/07/2016 20:39, Jason Gunthorpe wrote:
On Tue, Jul 19, 2016 at 06:23:32PM +0300, Matan Barak wrote:
+DECLARE_UVERBS_TYPE(
+ mlx5_device,
+ UVERBS_CTX_ACTION(
+ DEVICE_ALLOC_CONTEXT, uverbs_get_context, NULL,
+ &uverbs_get_context_spec,
+ &UVERBS_ATTR_CHAIN_SPEC(
+ /*
+ * Declared with size 0 as we current provide
+ * backward compatibility (0 = variable size)
+ */
+ UVERBS_ATTR_PTR_IN(ALLOC_UCONTEXT_IN, 0),
+ UVERBS_ATTR_PTR_OUT(ALLOC_UCONTEXT_OUT, 0),
+ ),
+ ),
+ UVERBS_ACTION(
+ DEVICE_QUERY, uverbs_query_device_handler, NULL,
+ &uverbs_query_device_spec,
+ ),
+);
The entire point of getting rid of the lists and changing the destruct
ordering was to avoid the need to have this kind of stuff in the
drivers.
I really don't want to see driver changes to implement the basic
API..
You could declare entire types in a common space (and these two examples
qualify for common declarations). However, if one wants to add driver
specific arguments for this command (besides some general arguments which
could be driver dependent), it needs to be in a driver specific files.
I think this is a good trade-off between driver specific arguments, commands
and types while sharing common handlers and command descriptors.
Are you going to fix and test every driver in the kernel?
In the interests of sanity, I think you need to provide a
straightforward way to retain the status-quo udata, at least as an
interm step..
I'm not excited to see things start here..
As an interm step, we use udata (see the actual example). By using that,
these actions could be in a common place. However, IMHO since we
declared this is a driver specific ABI where each driver could implement
and use whatever attributes it wants and create new types and actions, I
don't think we should differentiate between common attributes and driver
specific attributes (as it's the driver which decides whats common and
whats not).
Therefore, udata is great as an interm step avoiding changing
everything, but as a last step it might be better to go with standard
array of attributes.
Jason
Matan
--
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
