Re: [RFC ABI V2 8/8] RDMA/mlx5: Add mlx5 initial support of the new infrastructure

On 21/07/2016 19:49, Jason Gunthorpe wrote:

On Thu, Jul 21, 2016 at 02:38:28PM +0300, Matan Barak wrote:

quoted

On 20/07/2016 20:39, Jason Gunthorpe wrote:

quoted

On Tue, Jul 19, 2016 at 06:23:32PM +0300, Matan Barak wrote:

quoted

+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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html