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