On 12/16/19 11:19 AM, Andrew Rybchenko wrote:
> 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.
You're right, maybe we could request the technical board agree on that.
Next tech board is this wednesday.
I'm sending the request to the techboard ML.
Thanks,
Maxime
> 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.
>>>
>>
>
