* HFI1 code duplication todo @ 2015-11-12 21:13 Dennis Dalessandro [not found] ` <20151112211317.GB11252-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Dennis Dalessandro @ 2015-11-12 21:13 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, dledford-H+wXaHxf7aLQT0dZR+AlfA, ira.weiny-ral2JQCrhuEAvxtiuMwx3w, mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w 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. Thanks -Denny -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20151112211317.GB11252-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>]
* Re: HFI1 code duplication todo [not found] ` <20151112211317.GB11252-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org> @ 2015-11-19 22:23 ` Dennis Dalessandro 2015-11-20 13:12 ` Dan Carpenter 2015-11-20 15:41 ` Doug Ledford 0 siblings, 2 replies; 13+ messages in thread From: Dennis Dalessandro @ 2015-11-19 22:23 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, dledford-H+wXaHxf7aLQT0dZR+AlfA, ira.weiny-ral2JQCrhuEAvxtiuMwx3w, mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w 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. Thanks -Denny -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo 2015-11-19 22:23 ` Dennis Dalessandro @ 2015-11-20 13:12 ` Dan Carpenter 2015-11-20 15:41 ` Doug Ledford 1 sibling, 0 replies; 13+ messages in thread From: Dan Carpenter @ 2015-11-20 13:12 UTC (permalink / raw) To: Dennis Dalessandro; +Cc: linux-rdma, devel, dledford, gregkh At the beginning when hfi1 was put into staging, then it was easy enough for Greg to take those patches but now it feels awkward. Probably Doug and the linux-rdma@vger.kernel.org people should start maintaining the drivers/staging/rdma directory. Like merge Greg's tree and pull in whatever checkpatch fixes are still on the list and then take over from there... regards, dan carpenter ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo 2015-11-19 22:23 ` Dennis Dalessandro 2015-11-20 13:12 ` Dan Carpenter @ 2015-11-20 15:41 ` Doug Ledford [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (2 more replies) 1 sibling, 3 replies; 13+ messages in thread From: Doug Ledford @ 2015-11-20 15:41 UTC (permalink / raw) To: Dennis Dalessandro, linux-rdma, devel; +Cc: gregkh [-- Attachment #1.1: Type: text/plain, Size: 2864 bytes --] 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). 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. -- Doug Ledford <dledford@redhat.com> GPG KeyID: 0E572FDD [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] [-- Attachment #2: Type: text/plain, Size: 169 bytes --] _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* RE: HFI1 code duplication todo [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-11-20 15:49 ` Marciniszyn, Mike 2015-11-20 16:39 ` Greg KH 1 sibling, 0 replies; 13+ messages in thread From: Marciniszyn, Mike @ 2015-11-20 15:49 UTC (permalink / raw) To: Doug Ledford, Dalessandro, Dennis, linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Weiny, Ira > > 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. > There are inflight patches in two states right now: 1. Accepted into staging testing 2. Being debated on the list. How do we want to handle those? I would hate to miss a patch. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-11-20 15:49 ` Marciniszyn, Mike @ 2015-11-20 16:39 ` Greg KH [not found] ` <20151120163935.GA10091-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Greg KH @ 2015-11-20 16:39 UTC (permalink / raw) To: Doug Ledford Cc: Dennis Dalessandro, linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, ira.weiny-ral2JQCrhuEAvxtiuMwx3w, mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > 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 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. And the hfil1 code really doesn't look like its ready to merge into the "real" portion of the kernel tree, given the horrid nature of the patches submitted recently for it :( I had expected the drivers to be deleted for -rc1, removing them now seems a bit late in the merge window. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20151120163935.GA10091-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>]
* Re: HFI1 code duplication todo [not found] ` <20151120163935.GA10091-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> @ 2015-11-20 16:58 ` Doug Ledford [not found] ` <564F512A.1060808-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Doug Ledford @ 2015-11-20 16:58 UTC (permalink / raw) To: Greg KH Cc: Dennis Dalessandro, linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, ira.weiny-ral2JQCrhuEAvxtiuMwx3w, mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w [-- Attachment #1: Type: text/plain, Size: 2361 bytes --] On 11/20/2015 11:39 AM, Greg KH wrote: > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: >> 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 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. > And the > hfil1 code really doesn't look like its ready to merge into the "real" > portion of the kernel tree, given the horrid nature of the patches > submitted recently for it :( I'm sorry, that doesn't make sense to me. How can the quality of patches that aren't part of the driver yet and are just being submitted impune the readiness of the code the patches are supposed to be touching? 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. > 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. -- Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG KeyID: 0E572FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <564F512A.1060808-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: HFI1 code duplication todo [not found] ` <564F512A.1060808-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-11-20 17:01 ` Christoph Hellwig 2015-11-20 17:13 ` Greg KH 1 sibling, 0 replies; 13+ messages in thread From: Christoph Hellwig @ 2015-11-20 17:01 UTC (permalink / raw) To: Doug Ledford Cc: Greg KH, Dennis Dalessandro, linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, ira.weiny-ral2JQCrhuEAvxtiuMwx3w, mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn Hi Doug, before the drivers stops overloading writev vs write (hfi1_file_ops) it MUST not be moved to the main tree. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo [not found] ` <564F512A.1060808-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-11-20 17:01 ` Christoph Hellwig @ 2015-11-20 17:13 ` Greg KH [not found] ` <20151120171346.GA14829-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Greg KH @ 2015-11-20 17:13 UTC (permalink / raw) To: Doug Ledford Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b On Fri, Nov 20, 2015 at 11:58:18AM -0500, Doug Ledford wrote: > On 11/20/2015 11:39 AM, Greg KH wrote: > > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > >> 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 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. > > And the > > hfil1 code really doesn't look like its ready to merge into the "real" > > portion of the kernel tree, given the horrid nature of the patches > > submitted recently for it :( > > I'm sorry, that doesn't make sense to me. How can the quality of > patches that aren't part of the driver yet and are just being submitted > impune the readiness of the code the patches are supposed to be touching? They imply that the quality of the existing code is very low, if the authors can't submit valid changes to the existing files :) > 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. 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. > > 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), 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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20151120171346.GA14829-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>]
* Re: HFI1 code duplication todo [not found] ` <20151120171346.GA14829-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> @ 2015-11-20 17:46 ` Doug Ledford 0 siblings, 0 replies; 13+ messages in thread From: Doug Ledford @ 2015-11-20 17:46 UTC (permalink / raw) To: Greg KH Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b [-- Attachment #1: Type: text/plain, Size: 3710 bytes --] 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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG KeyID: 0E572FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo 2015-11-20 15:41 ` Doug Ledford [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-11-20 15:58 ` ira.weiny 2015-11-20 22:25 ` Dan Carpenter 2 siblings, 0 replies; 13+ messages in thread From: ira.weiny @ 2015-11-20 15:58 UTC (permalink / raw) To: Doug Ledford; +Cc: linux-rdma, devel, gregkh 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo 2015-11-20 15:41 ` Doug Ledford [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-11-20 15:58 ` ira.weiny @ 2015-11-20 22:25 ` Dan Carpenter 2015-11-21 15:53 ` ira.weiny 2 siblings, 1 reply; 13+ messages in thread From: Dan Carpenter @ 2015-11-20 22:25 UTC (permalink / raw) To: Doug Ledford; +Cc: linux-rdma, devel, gregkh On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > 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. You could leave it staging but manage it from the same git tree. It avoids the cross tree dependencies. This is what we do for drivers/staging/media/, all that stuff goes through the linux-media tree. regards, dan carpenter ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HFI1 code duplication todo 2015-11-20 22:25 ` Dan Carpenter @ 2015-11-21 15:53 ` ira.weiny 0 siblings, 0 replies; 13+ messages in thread From: ira.weiny @ 2015-11-21 15:53 UTC (permalink / raw) To: Dan Carpenter Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r On Sat, Nov 21, 2015 at 01:25:23AM +0300, Dan Carpenter wrote: > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > > 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. > > You could leave it staging but manage it from the same git tree. It > avoids the cross tree dependencies. This is what we do for > drivers/staging/media/, all that stuff goes through the linux-media > tree. My concern is that we tried this before and it did not work. https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg27842.html https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg27858.html Shall we try it again? Ira -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-11-21 15:53 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-12 21:13 HFI1 code duplication todo Dennis Dalessandro [not found] ` <20151112211317.GB11252-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org> 2015-11-19 22:23 ` Dennis Dalessandro 2015-11-20 13:12 ` Dan Carpenter 2015-11-20 15:41 ` Doug Ledford [not found] ` <564F3F1C.4020508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-11-20 15:49 ` Marciniszyn, Mike 2015-11-20 16:39 ` Greg KH [not found] ` <20151120163935.GA10091-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 2015-11-20 16:58 ` Doug Ledford [not found] ` <564F512A.1060808-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-11-20 17:01 ` Christoph Hellwig 2015-11-20 17:13 ` Greg KH [not found] ` <20151120171346.GA14829-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> 2015-11-20 17:46 ` Doug Ledford 2015-11-20 15:58 ` ira.weiny 2015-11-20 22:25 ` Dan Carpenter 2015-11-21 15:53 ` ira.weiny
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.