On Thu, Sep 01, 2016 at 11:29:21AM -0400, ira.weiny wrote: > > Erm, but we already have a mess. AFAIK Mellanox and Intel both use > > OFED derivatives as their main means to deliver fixes to customers > > that both entirely replace the distro stack and completely conflict > > with each other. > > OPA's "delta install" is _not_ based on OFED and installs only the bits which > are needed beyond what is in the distro. Many of those changes already appear > in upstream repos which have not made it into the specific distro version. As > things are accepted we drop those bits from our install. This has been our > policy for some time and if you look at our IFS download you can see that the > packages which get installed for newer distros like 7.2 are smaller than > previous versions. Cool, I am behind the times on that I guess. However, the my point remains, it still clashes with what MOFED does, and the idea of two vendors not stomping on each other is still ficitional. > To some extent this supports Woody's position. libhfi1verbs is being used by > many customers because we can supply it without breaking the standard > libibverbs install. NOTE in Fedora, RHEL, SLES, and others we _do_ _not_ > update libibverbs. Thus keeping the standard distro support intact for other > vendors hardware. Well only in the sense that you are on a path that makes it hard to get into the distros thus requiring you jump through hoops to distribute your software.. Lets focus on the actual problem :) > > > 2.) Allow a vendor the ability to distribute their library package > > > separately from the bundled package. > > > > There is nothing stoping this, it is trivial for the vendor to make a > > .spec file for rdma-plumbing that just produces a rpm with the single > > vendor provider (after doing the full build). > > > > If you really want an example I will show you. > > That could be an alternative. > > > > > > 3.) Allow the ability for a vendor to distribute an update package > > > that just contains their library code to replace the version of that > > > code that is in the bundled package. I think that OFI, for example, > > > has something like this to avoid this kind of mess. > > > > Certainly, we can make this even easier as well. Mainly what is needed > > is some way for the vendor to drop in a override .driver file in > > /etc/ibverbs.d/ > > > > It would not be hard to make a patch that does that, if that is all it > > takes to alleviate your concern I can add it to the todo list. > > Agreed. FWIW I would just add such external updates to an "updates" directory > so that users can easily see that something extra was installed. But this is a > minor point. I'll write a patch to enable 'run from build' in a way which should make this even more straight forward. However, things are already fine today, you just drop your driver in /opt/intel-opa/lib/libhfi1.so and customize /etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I wrote the absolute path patch for this years ago for exactly this reason) 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
