Re: HFI1 code duplication todo

["ira.weiny" <ira.weiny@intel.com>]

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote:
> On 11/19/2015 05:23 PM, Dennis Dalessandro wrote:
> > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote:
> >> The major todo for the hfi1 driver in staging is getting rid of the
> >> verbs code duplication between ipath, qib, and now hfi1. The ipath
> >> driver has been deprecated and is going to be deleted soon. So that
> >> leaves qib and hfi. To address this we have proposed rdmavt which will
> >> be a common kmod that provides software RDMA verbs support. qib and
> >> hfi1 will both use this as well as other forthcoming drivers such as
> >> soft-roce. See this thread for some details:
> >> http://www.spinics.net/lists/linux-rdma/msg29922.html.
> >>
> >> Since that initial RFC we have been accumulating patches in a GitHub
> >> repo for an early look at the development. At some point soon we want
> >> to actually start posting the patches to the mailing list. This is
> >> where it gets tricky.  The code basically not only adds a new driver
> >> but it modifies two existing ones, heavily. To make it more murky one
> >> driver is in staging the other is in the usual drivers/infiniband tree.
> >>
> >> The question is, how do we go about this logistically due to the 2
> >> drivers being in separate sub-trees?
> >>
> >> Greg, Doug,
> >> As the maintainers of the two trees involved we'd kind of like to get
> >> your thoughts on this.
> > 
> > Hi Greg and Doug,
> > 
> > Just wanted to ping you guys again in case my mail last week slipped
> > through the cracks. We are at the point now where we have some patches
> > we can start posting. Looking for some logistical guidance.
> 
> Sorry, I've been out for a while now with the birth of my second child.
>  Things have settled down enough around here that I should be able to
> get things going again (at least well enough to be more responsive to
> email anyway).

Congratulations!

> 
> So, as to the hfi1/qib/rxe transport library.  The qib driver is in the
> rdma tree, and we aren't going to move it to staging just because it
> depends on something in staging, so we need to start adding the library
> in the core tree to avoid dependency issues.  As for the hfi1 driver,
> I'm of the opinion that putting it in staging because of the code
> duplication issue was probably not the right thing to do.  It's
> benefited from the extra eyes on it to help make it a better driver, but
> I think I'm ready to move it to the main RDMA tree and start working on
> it from there where there won't be any cross tree dependency issues.
> 
> To that end, I've opened my 4.4-rc branch and deleted the three
> deprecated drivers from staging and moved hfi1 to the rdma tree.  I've
> sent an email to Linus to see if he's ok taking those changes, and if
> so, I'll get them submitted and then open up my for-4.5 branch early to
> be able to start taking for-next patches.

I agree this is the correct way to go.

However, we have patches which are either in staging-next, staging-testing, or
in flight.

How should we handle those?  I propose.

Greg can ignore the patches in flight.  We have reworks on them anyway.  Those
which just went in to staging-testing can get dropped and we will resubmit
them.

For those which are in staging-next we can submit revert patches to avoid
merge conflicts and resubmit those as well.  This is the item I am not sure
about?

Or is there a better more standard way of handling this?

Ira