Jeff wrote, >Yow! We need a technology/system/process/whatever for allowing >vendors to distribute what they need without effectively forking OFED >to make their own "<vendorX> OFED". Even if <vendorX> OFED *should* >be the same as community OFED, it sometimes (?usually?) is different >in very subtle/small-but-important ways (e.g., vendorX compiling/ >installing vendorY's drivers, but not QA'ing them). To be clear: with >each vendor putting out their own different versions of OFED, it makes >for big user confusion about compatibility and ecosystem.
I see this as a probalem as well. I think that some cases, the forked OFED stacks are a superset of OFED plus other vendor supplied stuff, like firmware for their card. If they are however removing support for the other IHV's drivers, I see this as a problem. I think that if we split all of the common code from the kernel RPM into it's own RPM and each IHV provide RPMs for their drivers (as I suggested in the last EWG meeting), that should help this problem as then a vendor supplied release could contain exactly the RPMs from OFED and not a derivative that removes support for another vendor's hardware. my 2 cents. woody -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Thursday, June 11, 2009 4:49 AM To: Pavel Shamis (Pasha) Cc: [email protected] Subject: Re: [ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of OFED? On Jun 9, 2009, at 6:49 AM, Pavel Shamis (Pasha) wrote: > The excluding of MPI from OFED, will only push users to use vendor > specific OFED builds (that provides MPI out of box) and I'm not sure > that it is good for OFED community. > Pasha and I discussed exactly this point in IM and we agreed to disagree. :-) FWIW, I think this point touches on an issue that is deeper than just MPI in OFED. Different vendors having their own [potentially incompatible] versions of OFED -- each with different value-add -- is both good and bad. GOOD: vendors can innovate and differentiate BAD: it seems like the bad old days of different/incompatible vendor versions of mVAPI: <vendorX> OFED != <vendorY> OFED != <community> OFED I've heard similar stories from many users, "I have <vendorX> OFED -- is that the same/compatible as <vendorY/community> OFED?" And sometimes the answer is "not entirely". Yow! We need a technology/system/process/whatever for allowing vendors to distribute what they need without effectively forking OFED to make their own "<vendorX> OFED". Even if <vendorX> OFED *should* be the same as community OFED, it sometimes (?usually?) is different in very subtle/small-but-important ways (e.g., vendorX compiling/ installing vendorY's drivers, but not QA'ing them). To be clear: with each vendor putting out their own different versions of OFED, it makes for big user confusion about compatibility and ecosystem. Note that Pasha's answer at least somewhat implies that he feels the same way. :-) -- Jeff Squyres Cisco Systems _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
