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

[Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>]

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