On 12/10/2015 11:10 AM, Steve Wise wrote: > > >> -----Original Message----- >> From: linux-rdma-ow...@vger.kernel.org >> [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Chuck Lever >> Sent: Thursday, December 10, 2015 10:08 AM >> To: linux-rdma@vger.kernel.org >> Cc: ira.weiny; Christoph Hellwig; Jason Gunthorpe; Or Gerlitz; Steve Wise; >> Or Gerlitz; Sagi Grimberg; Doug Ledford >> Subject: Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly) >> >> >>> On Dec 10, 2015, at 3:27 AM, Sagi Grimberg <sa...@dev.mellanox.co.il> 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. >> >> > > The approach sounds reasonable to me.
This isn't a bad plan if we go that way.
Now here's where I get to speak my mind on things (since people have
been asking).
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
