> On 07/17/2015 02:14 AM, Greg Kroah-Hartman (gregkh@xxxxxxxxxxxxxxxxxxx) > wrote: > > > > It's up to the IB maintainer if they are willing to let it be in > > stable as-is. > > I wouldn't call it stable as-is. However, that doesn't mean I think it > *must* go to staging. It's a first cut at a totally new driver. It's got issues, but > they aren't horrible by my estimate. I don't consider staging a necessary step, > although I wouldn't preclude it either. Doug, >From this response it seems that the following would be an acceptable path forward. 1) Mike submits V4 of the new driver patch set which has all the changes we have committed to thus far; document the sysfs use. 2) you accept this V4 patch set into the InfiniBand subtree. 3) Further changes to fix the issues you mention above happen incrementally via individual patches which can be easier to discuss on the mailing list. The alternative which Mike was proposing was to change step 2 to be acceptance to Staging. This is because we want to make sure that any changes we do are acceptable within the community and it is going to be difficult for the community to see how those changes are shaping up with massive driver patch sets where the bulk of the code is _not_ changing. > > > If so, sure, but it needs to be stand-alone and have a TODO file > > listing what needs to be done. If no forward progress happens on it, > > I will delete it from the tree, this isn't a place for dumping code. > > No, it's 50,000+ LOC already. I don't see "no forward progress" as likely. > This is why we are looking for a place to put the "base" code. Then we can better discuss changes without resubmitting a new version of a 50K line patch set. If going into the InfiniBand subtree is acceptable then we would prefer that. Thanks, Ira _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
