> On Dec 10, 2015, at 3:27 AM, Sagi Grimberg <[email protected]> wrote: > > > >> Doug this is going to conflict with the rdmavt work. So if you take this >> could >> you respond on the list. > > It will also conflict with the iser remote invalidate series. > > Doug it would help if you share your plans so people can rebase > accordingly.
I would be remiss not to mention that it probably also conflicts with the NFS server bi-directional RPC/RDMA series. Invasive IB core changes like this clean up are especially burdensome for me because NFS/RDMA changes do not normally go through Doug's tree, so it takes extra co-ordination. Here is a modest proposal. An obvious way to split the device attr cleanup might go like this: a. first patch: add new fields to ib_device b. then one patch for each provider to populate these fields c. then one patch for each kernel ULP to use the new fields d. then one patch for each provider to remove ->query_attr e. last patch: remove ib_device_attr from the IB core That way each provider and ULP maintainer can review and ack the portion of the changes that he or she is responsible for, and it should help make it much easier to merge with conflicting changes. Splitting it across more than one kernel release would be helpful too, IMO. a. and b. can go into 4.5, c. into 4.6, and d. and e. can go in any time after that. This adds more "process" but given the long chain of core changes now in plan, we should acknowledge how disruptive they will be, and come up with ways to make it possible to get other work done while the core maintenance work progresses. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
