Doug Ledford wrote,
>The OFA has already learned their lesson once with XRC. I wonder if they are getting ready to get hit with another lesson over this. The issue is if the OFA ships an API and it isn't upstream, then that API needs to legitimately be a >private, should never conflict with upstream API. If upstream then implements the same thing in a different way and users are exposed to the rather unpleasant choice of code to OFA's API or to upstream's API for the same thing, it >creates a schism in the user's code base around what API to use/support. This is entirely contrary to the OFA's stated goals about the end user experience of people using their RDMA software. So Intel can certainly make any cost >analysis they want about their hardware and the software to support it, but the OFA is not Intel's personal software distributor and the OFA must look at other, bigger picture issues than Intel.
The Xeon-Phi code is somewhat different than what happened in the past with XRC. In the case of XRC, it was integrated into the base OFED package and built-in by default. For the Xeon-Phi code,
it is clearly marked as a technology preview and is not even compiled in at all unless specifically enabled. This is not too terribly different than the experimental branches that the kernel has.
Also, the Xeon-Phi code does not add any new APIs. It simply implements a driver set and library, thus there is no risk in someone coding to an API in OFED that gets totally changed once it gets upstream. The EWG charter allows code that is not upstream to be added as a technology preview. This allows people that want it, to try it out and use it. I personally do not see a reason to change that. You may not like what we are doing, and if you are an OFA promoter member, you could ask for a vote of the board to change the bylaws to prevent it. In the absence of that, you really do not have a say in the matter.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
