On Sat, Sep 23, 2017 at 11:03:25AM -0400, Doug Ledford wrote: > That's my answer to people not necessarily wanting to wait until kernel > n+1 to use features they put in their net driver in kernel n. So, this > applies to the mlx4, mlx5, cxgb3, cxgb4, bnxt_re, hns_roce, and i40iw > drivers off the top of my head. A different possible model would be to more broadly accept pull requests for drivers and push the work to synchronize with other parts of the tree directly to the driver folks, instead of trying to coordinate it all yourself. When a driver sends you a PR it will have to be 'clean' and be based on accepted shared commits already in Linus's tree, in the net tree and in the rdma-core tree. Ignoring shared commits, the PR can only touch drivers/infiniband/hw/xxx. No uAPIs. Each driver team can decide how they want to construct their PR within those guidelines. Set a cut off of rc6 or something for these driver PRs to give time to sort out any RDMA merge issues. Run the core and ULP parts as a normal tree with a normal work flow, don't integrate tricky driver PRs into the normal tree until the merge window. Make sure this flow runs fast enough that the driver people can pull from here when constructing their driver branch. Run a single 'volatile' for-next tree that merges all pending branches, including driver PRs. This is the early warning for merge problems. When the merge window comes around decide what to branches to send based on what is in Linus's tree already. Maybe two PRs per merge window will be needed to sort out dependencies, depends how fast net/etc are at getting merged. I think other subsystems do this already? The advantage is *you* are largely no longer worrying about timing or monitoring the net tree or anything like that. The driver teams take full responsibility to do that in a set time window. Either they post an acceptable PR in time or they miss the merge window. Some scripting is possible so you can determine on a daily basis when driver PRs become 'clean' and thus sendable to Linus. Eliminates some of the manual coordination. Another advantage is QA. When the driver teams QA their PR, they are now QA'ing something with all dependent changes, and the configuration they QA'd is recorded in the git history instead of being lost when patches get rebased as they flow through patchworks. They have more certainty what they will QA and they do not have to run so many various speculative combinations. I belive this is broadly similar to what arm-soc does for how they manage the SOC maintainers, and deal with their crazy cross-tree dependencies. Review one of their presentations: http://events.linuxfoundation.org/sites/events/files/slides/Maintaining%20a%20large%20kernel%20subsystem_0.pdf And imagine things like SOC's are our drivers (eg omap == mlx) arm-soc does a bit more than just this, their downstreams split patches eg into fixes/fixes-non-critical, etc. RDMA could do that do. People are asking for more certainty, the best way I can think to provide that is to let them run their own sub-tree within certain fairly tight boundaries. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
