Re: [dpdk-dev] discussion: creating a new class for vdpa drivers

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 12/16/19 1:04 PM, Maxime Coquelin wrote:
> 
> 
> On 12/16/19 10:39 AM, Andrew Rybchenko wrote:
>> Hi Maxime,
>>
>> On 12/16/19 11:50 AM, Maxime Coquelin wrote:
>>> Hi Andrew,
>>>
>>> On 12/16/19 9:46 AM, Andrew Rybchenko wrote:
>>>> On 12/16/19 11:29 AM, Matan Azrad wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>> I understand all of you agree \ not object with the new class for vdpa drivers.
>>>>
>>>> I have two control questions:
>>>>
>>>> 1. If so, is it allowed to have vDPA driver in
>>>>    drivers/net/<driver> if it is better from code sharing point
>>>>    of view?
>>>
>>> If it has something to share, I think we should move the common bits
>>> to the common directory.
>>
>> Does it mean that it is *not* allowed to have vdpa driver in
>> drivers/net/<driver> and vDPA drivers *must* live in
>> drivers/vdpa only?
> 
> I would say yes, for consistency.

OK, it makes sense. Consistency is good.

> But that's just my point of view.
> Do you have an argument in favor of not enforcing it?

I simply expect (storm of) patches which do factor/move out
etc. No strong opinion right now. Just clarifying suggested
policy.

Thanks,
Andrew.

> Thanks,
> Maxime
> 
>>>> 2. If drivers/common is used, is exported functions which are
>>>>    used by drivers/net/<driver> and drivers/vdpa/<driver> and
>>>>    data structures are a part of public API/ABI? Hopefully not,
>>>>    but I'd like to double-check and ensure that it is solved in
>>>>    the case of shared libraries build.
>>>
>>> Common functions and data should not be part of the API/ABI I agree.
>>> I guess we should use relative paths for including the common headers.
>>
>> Hopefully include_directories() with relative path in the case
>> of meson.build.
>>
>