On Thu, May 05, 2016 at 03:39:32PM +0300, Leon Romanovsky wrote: > > I think the message really should be that if your driver contains uAPI > > changes those should be in separate patches that are clearly identified. So > > if you have a driver that is developed off-list initially, instead of just > > breaking it up into chunks for submission add another step. > > > > Something like this: > > 1) Submit patch series which break-ups internally developed code > > 2) Submit patch series with separated out uAPI code > > 3) Submit patch that makes the build go-live Yes. Perhaps even submit #2 after getting #1 mainlined. Make it easy to find the important/controversial things and the review process will work much better for everyone. Buring stuff in a monster patch is just going to stretch it out. > > These can all be submitted together, but with the patches broken up like > > this reviewers can target uAPI code more easily. > At the end, there is no point of accepting (1) without finished review > of (2 and 3). Right now all patch series already have such internal separation > in a slightly different order. Eh? Drivers should be able to stand alone without dedicated uapis (excluding the udata stuff). For instance, the HFI1 driver is as functional as any other RDMA driver without it's cdev, eeprom, debug and sysfs uAPIs. Those are all value add features that do not impact the driver's ability to operate as an RDMA device. 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
