> Or - the agreement in Sonoma was that anything submitted to OFED should > also be in the process of going into the kernel. Because Roland can't > always respond in the time frame required to match the OFED schedule, we > explicitly said it didn't have to be accepted. If it turns out that > there is some major issue with the change in question ( which has been > submitted upstream), we'll respond to that. But I also don't want to > either hold up the release, or redo an entire set of patches because of > this one (relatively small) change.
<rant> This is to a large degree hogwash. The entire qib driver was shipped in an OFED release long before it was even submitted upstream for the first time. So this change in particular is not a big deal but the development methodology of completely throwing away the upstream ipath driver and shipping a new codebase (of 50,000+ lines of code!) as part of OFED seems pretty broken to me. To be honest I think the qib driver is a symptom of a pretty big problem. Looking at the git logs, I see that we merged the ipath driver around March 2006, and the last patch from qlogic in December 2008. So it took you guys about 2.5 years to decide that your first driver was an unmaintainable mess and had to be thrown away. I see many signs of the same philosophy of "our needs don't match the existing kernel facilities perfectly, so let's hack around it or reimplement it in device-specific driver in an ugly way rather than working outside our driver to fix the interface" in qib. Given the track record of quickly giving up on code as unmaintainable, I'm hoping we can at least get the qib driver into shape where the community can continue to keep things together if you guys give up on it. </rant> - R. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg