On Thu, May 05, 2016 at 12:08:43PM -0600, Jason Gunthorpe wrote: > 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). And they are, however the point is a little bit different. There is no meaning in internal feature implementation without access through verbs interface. > > 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. Let's close for them PSM and verbs interfaces and see how it is operable. > > Jason
Attachment:
signature.asc
Description: Digital signature
