Sun, Mar 04, 2018 at 01:26:53AM CET, alexander.du...@gmail.com wrote: >On Sat, Mar 3, 2018 at 1:25 PM, Jiri Pirko <j...@resnulli.us> wrote: >> Sat, Mar 03, 2018 at 07:04:57PM CET, alexander.du...@gmail.com wrote: >>>On Sat, Mar 3, 2018 at 3:31 AM, Jiri Pirko <j...@resnulli.us> wrote: >>>> Fri, Mar 02, 2018 at 08:42:47PM CET, m...@redhat.com wrote: >>>>>On Fri, Mar 02, 2018 at 05:20:17PM +0100, Jiri Pirko wrote: >>>>>> >Yeah, this code essentially calls out the "shareable" code with a >>>>>> >comment at the start and end of the section what defines the >>>>>> >virtio_bypass functionality. It would just be a matter of mostly >>>>>> >cutting and pasting to put it into a separate driver module. >>>>>> >>>>>> Please put it there and unite the use of it with netvsc. >>>>> >>>>>Surely, adding this to other drivers (e.g. might this be handy for xen >>>>>too?) can be left for a separate patchset. Let's get one device merged >>>>>first. >>>> >>>> Why? Let's do the generic infra alongside with the driver. I see no good >>>> reason to rush into merging driver and only later, if ever, to convert >>>> it to generic solution. On contrary. That would lead into multiple >>>> approaches and different behavious in multiple drivers. That is plain >>>> wrong. >>> >>>If nothing else it doesn't hurt to do this in one driver in a generic >>>way, and once it has been proven to address all the needs of that one >>>driver we can then start moving other drivers to it. The current >>>solution is quite generic, that was my contribution to this patch set >>>as I didn't like how invasive it was being to virtio and thought it >>>would be best to keep this as minimally invasive as possible. >>> >>>My preference would be to give this a release or two in virtio to >>>mature before we start pushing it onto other drivers. It shouldn't >>>take much to cut/paste this into a new driver file once we decide it >>>is time to start extending it out to other drivers. >> >> I'm not talking about cut/paste and in fact that is what I'm worried >> about. I'm talking about common code in net/core/ or somewhere that >> would take care of this in-driver bonding. Each driver, like virtio_net, >> netvsc would just register some ops to it and the core would do all >> logic. I believe it is essential take this approach from the start. > >Sorry, I didn't mean cut/paste into another driver, I meant to make it >a driver of its own. My thought was to eventually create a shared/core >driver module that is then used by the other drivers. > >My concern right now is that Stephen has indicated he doesn't want >this approach taken with netvsc, and most of the community doesn't
IIUC, he only does not like the extra netdev. Is there anything else? >want the netvsc approach applied to virtio. Until that impasse can be >resolved there isn't much value in trying to split this up so it is >available to other drivers. In addition I would imagine it would make >it a pain for others to back-port into distros since it would break >legacy netvsc driver behavior. Patches are always welcome. Once this >is in you are free to try fighting to get this made into a generic >module and applied to both drivers, but we have already spent close to >3 months on this and it seems like there has been significantly more Alex, time is never a good argument for poor design and shortcuts. >time spent arguing over the number of interfaces and/or drivers than >spent writing/reviewing actual code. > >- Alex
