On Thu, 2 Sep 2010 13:35:44 -0700 Hal Rosenstock <hal.rosenst...@gmail.com> wrote:
> Hi Ira, > > On Tue, Aug 31, 2010 at 3:49 PM, Ira Weiny <wei...@llnl.gov> wrote: > > On Tue, 31 Aug 2010 02:27:29 -0700 > > Yevgeny Kliteynik <klit...@gmail.com> wrote: > > > >> Hi all, > >> > >> In order to support RoCEE, a while ago I've added > >> a new field to umad, thus introduced an ABI change. > >> > >> There already was a discussion on the linux-rdma list, > >> but due to the proximity of the upcoming OFED 1.5.2 > >> release these concerns were raised again. > >> > >> So my question is, other that *general* concerns about > >> changing ABI, is anybody aware of the *actual* problem > >> that will be caused by this? Any customer/3rd party > >> solution that would be affected by this? > > > > Because our MVAPICH depends on umad, libibumad.so.1 to be exact.[*] These > > ABI > > changes (to v2 and v3) would have forced our users to recompile their codes. > > We are maintaining the old ABI here until our next major release of CHAOS[#] > > to prevent this. > > > > I think the thing to remember is that many people are using Open Fabrics > > software, but are _not_ using "OFED". What is tested with OFED is not the > > only thing which might be using these libraries. Our version of MVAPICH is > > a > > good example. > > > > I am certainly not the expert in this area and I know that many people have > > tried to make this point in the past, but I will say it here again. Each of > > these Open Fabrics packages _must_ be maintained to stand on their own. > > Roland did this a long time ago with ibverbs. > > > > I think now is a good time to start discussing breaking up the "management" > > git > > tree so that these libraries can live on their own. > > How does breaking up the "management" git tree help with this issue ? Creating and tracking of branches to maintain ABI would be easier with separate git trees. Furthermore, separate trees will help "force" the use of consistent ABI's and interfaces. For example, if I currently want OpenSM version 3.3.6 I get a management tree with version libibumad 1.3.5. But this last ABI change to umad was only required for the latest infiniband-diags (ibstat utility). Why do I get all this "cruft" when pulling the latest OpenSM? > To me, that's the admin part and is separate from the ABI issue > raised. Yes it is separate. That is why I created another thread to discuss those issues. > > The ABI compatibility is not achieved by administrative means > (separate repos, etc.) but rather than review and discipline to > achieve this as a unmutable goal. I agree that ABI compatibility will require more discipline. That is what made me think of the separate git trees. I feel it will be _easier_ to maintain this discipline when the trees are separate. Ira > > -- Hal > > > I will write a separate email regarding this. > > > > Ira > > > > [*] We are looking into removing the dependency. > > [#] Shameless plug: > > http://*code.google.com/p/chaos-release/wiki/CHAOS_Description > > > >> > >> -- Yevgeny > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://**vger.kernel.org/majordomo-info.html > >> > > > > > > -- > > Ira Weiny > > Math Programmer/Computer Scientist > > Lawrence Livermore National Lab > > 925-423-8008 > > wei...@llnl.gov > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://*vger.kernel.org/majordomo-info.html > > > -- Ira Weiny Math Programmer/Computer Scientist Lawrence Livermore National Lab 925-423-8008 wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html