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

[Maxime Coquelin <maxime.coquelin@redhat.com>]

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.
But that's just my point of view.
Do you have an argument in favor of not enforcing it?

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.
>