[RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

Doug Ledford dledford at redhat.com
Wed Dec 23 04:21:56 UTC 2015


On 12/22/2015 09:27 PM, gregkh at linuxfoundation.org wrote:
> On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote:
>> On Mon, Dec 21, 2015 at 05:01:48PM -0800, gregkh at linuxfoundation.org wrote:
>>> On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote:
>>>> On Mon, Dec 21, 2015 at 02:02:35PM -0800, gregkh at linuxfoundation.org wrote:
>>>>> On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote:
>>>>>> Greg, Doug,
>>>>>>
>>>>>> As mentioned below, these patches depend on the new rdmavt library submitted to
>>>>>> Doug on linux-rdma.
>>>>>>
>>>>>> We continue to identify (and rework) patches by our other developers which can
>>>>>> be submitted without conflicts with this series.  Furthermore, We have, as much
>>>>>> as possible, placed fixes directly into rdmavt such that those changes can be
>>>>>> dropped from hfi1.  But at this point, we need to know if and where these are
>>>>>> going to land so that we can start reworking as appropriate.
>>>>>>
>>>>>> Therefore, I would like to discuss plans to get hfi1 under the same maintainer
>>>>>> to work through this transitional period.
>>>>>>
>>>>>> Basically, At what point should we stop submitting patches to Greg and start
>>>>>> submitting to Doug?
>>>>>>
>>>>>> Should we consider the merge window itself as the swap over point and submit
>>>>>> changes to Doug at that point?  If so, should we continue to submit what we can
>>>>>> to Greg until then (and continue rebase'ing the series below on that work)?  Or
>>>>>> given Gregs backlog, should we stop submitting to Greg sometime prior to the
>>>>>> merge window?
>>>>>>
>>>>>> That brings up my final question, at the point of swap over I assume anything
>>>>>> not accepted by Greg should be considered rejected and we need to resubmit to
>>>>>> Doug?
>>>>>
>>>>> If Doug accepts the library changes, let me know that public git commit
>>>>> and I can pull it into the staging-next branch and you can continue to
>>>>> send me staging patches that way.
>>>>
>>>> Won't this cause a conflict during the merge window?
>>>
>>> No, git is good :)
>>>
>>>> How do we handle changes which affect both qib and hfi1?
>>>
>>> I don't know, now this gets messy...
>>>
>>
>> Agreed and this is what we are worried about.
>>
>> Can we do what Dan and Doug have proposed in the past and have Doug take over
>> the staging/rdma sub-tree?
>>
>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html
>>
>> I think the upcoming merge window is a reasonable time for him to do that.
> 
> Ok, but keeping on top of all of the generic staging patches that come
> in is a tough thing to do, that's up to Doug, if he is ready for it...

I'm not worried about that.  Patchworks makes the workflow reasonable.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: 0E572FDD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/attachments/20151222/43accee5/attachment.asc>


More information about the devel mailing list