On Thu, Jul 05, 2018 at 11:47:43AM -0400, Dennis Dalessandro wrote: > >Okay.. > > > >I looked over this thing and I don't know what to say. > > So you see why Ira and I brought this up at OFA when we were all sitting > around at the networking event. :) We he didn't say it was such an enourmous patch > >It badly violates all accepted limits for patch size and patch series > >length. I don't see what you think anyone else is going to do with > >this. > > Oh I completely agree. Unfortunately I didn't see a better way to do this. > Kaike did a lot of work to try and break things up into logical chunks. Any > suggestions on how to make it more digestable, we are open to it? You must split it, I'm not sure why this is a problem? The obvious split is 5 series in something like responder RDMA WRITE support initiator RDMA WRITE support responder RDMA READ support initiator RDMA READ support enablement and negotiation And the weird patches with files full of empty functions seem ugly. Don't split things like that.. > Perhaps the thing to focus on is that we don't touch any uAPI, we don't > modify the ib_core. Everything is contained in our driver and can't cause > problems for any other drivers or core of the rdma sub system. Even so, accepting such large series means the maintainers are not doing a good job for the entire ecosystem. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
