On 05/04/2017 10:34 AM, Hefty, Sean wrote:
This is exactly why we so strongly discourage this out of tree
stuff - getting something unmergable in OFED is *NOT* Job Done,
Time to Go Home. Down this path just creates another Lustre mess.
Actually, this may be 'job done'. No individual or company is
obligated to provide upstream software for any of their hardware.
OFA decides what to ship in their software products, not the greater
linux kernel community. Individual companies can decide if out of
tree maintenance is more cost effective than trying to merge code
upstream. Because that's what this ultimately comes down to.
IMO, the only people who have legitimate complaints here are those
people running Xeon Phi with Mellanox HCAs who are being forced to
use OFED, rather than upstream code.
Apparently we've experimented with doing just this, so I'll bite.
And I will say the same thing we've told every vendor repeatedly: "get
your code upstream!"
A vendor may weigh the cost of maintaining out-of-tree code versus
upstreaming it, but as a customer, I'm more concerned about the
annoyance and time wasted having to run N different software stacks on N
different hardware types versus being able to use the RDMA stack from my
preferred linux distribution everywhere. And the best way to get your
code into the distributions is to get it upstream.
I have no particular opinion on whether or not the xeon-phi driver
belongs in OFED. But cloaking this conversation in talk of obligations
and framers' intent misses a bigger point, which is that any code not
fully upstreamed, and hence likely to be found in your user's distro,
inconveniences them, increases their support costs, and makes it less
likely that they will adopt your product.
Jim
--
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
