On 11/20/2015 12:13 PM, Greg KH wrote: >>> I think it's too late for that, especially given that I have 34+ patches >>> for the staging rdma drivers already in my tree in linux-next. >> >> For hfi1 rename detection should work, for the other three, patches to >> removed files are easily resolved as simply dropped patches. So I don't >> think it's that large of an issue. Correct me if I'm wrong. > > I don't know what kind of conflicts will happen, if the changes will > propagate over if you rename a file in one branch and expect the changes > made to the file in a different branch to come over. Haven't done that > in years.
Well, there's also the possibility of just me pulling your current
for-next and making that the starting point of my for-next and doing the
deletions and move there. That would resolve the issue.
>> And that's orthogonal to the issue that the primary TODO item for this
>> driver requires coordination between it, qib (in the RDMA tree), and the
>> upcoming soft_roce driver. If the driver isn't moved, then we have to
>> coordinate between your tree and mine to make sure that no patches are
>> taken into your tree until after the patches they depend on have landed
>> in my tree. And then you tree likely won't build unless you pull from
>> my tree and merge up first. It's not really tenable. That was why I
>> had suggested (and originally you agreed to) that I would handle the
>> entire staging/rdma tree. However, since you changed your mind on that
>> issue, we now have this coordination issue. I don't really want to deal
>> with that, so I would rather move the hfi1 driver and take care of the
>> all the needed patching myself going forward.
>
> That might be the _primary_ TODO item, but really, look at the patches
> being submitted so far, they are just fixing up basic things that should
> have been done a long time ago to the codebase.
Yes, I agree. The driver is in active development. It is not a mature
driver, and they are still fixing things up.
> How about people get it
> cleaned up "completely" for this merge cycle, going through my tree, and
> then, when it's all cleaned up, I'll move it to your portion of the tree
> and merge that into 4.5-rc1 and then the cross-driver/core changes you
> are referring to can happen. There's no big rush here to try to force
> the issue.
Other than the fact that people are ready to start on the initial
changes to support the library, there's no rush. But doing the move now
(even if just via my for-next branch) allows people to start submitting
those other patches. There are multiple people working on this driver,
some of them working on cleaning the driver up in general, and some
working on that transition to a core library for transfers. Getting the
driver moved allows those people to submit patches in parallel instead
of forcing serialization of the development flow.
>>> I had expected the drivers to be deleted for -rc1, removing them now
>>> seems a bit late in the merge window.
>>
>> Yes, I know. I've been busy. My apologies for not getting it in prior
>> to rc1.
>
> It's not a problem, life happens (congratulations by the way),
Thanks :-)
> but don't
> rush things now, why not just wait until the next merge window, there
> are no deadlines here that require this to happen for 4.4-final.
I'm actually not in a rush to get the deletions in, or to get the
cleanup patches to hfi1 in, I'm only trying to enable getting the
library development started. Right now, it's blocked.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
