On Tue, 19 Oct 2010 08:43:22 -0700 Hal Rosenstock <hal.rosenst...@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 11:28 AM, Hefty, Sean <sean.he...@intel.com> wrote: > >> > but is there a strong reason why ib_types.h can't be moved from > >> opensm/include/iba to libibumad/include/infiniband? > >> > >> Why does this need to be moved ? > > > > The dependency should be on libibumad, not opensm. libibumad is pretty > > much useless without these definitions. Why wouldn't you move them? > > Off the top of my head, OpenSM is layered on top of libibumad but > doesn't need/use libibmad. I think that was the main reason although > that could be changed if ib_types.h were to be moved. I'm not sure > what other reasons came up in the previous discussions. I think ib_types.h should be part of ibumad. Everything depends on libibumad at some point.[*] Therefore common mad definitions should be in ib_types.h and packaged with libibumad. [*] ok OpenSM does not strictly, see below. > > > > >> There already are diags including ib_types.h (saquery for one). > > > > Yes, but we're either stuck with everything that needs ib_types.h to be > > part of the management.git tree, or the app needs to depend on opensm. > > Currently, ibacm duplicates definitions because they aren't available > > anywhere else. > > I agree ib_types.h is more generic than opensm. Moving to libibmad and > making opensm depend on this is probably better than all the > duplication. There have been viewpoints that libibumad and libibmad > shouldn't be separate (as they are small) but they were never combined > into a single library. The opposing view is that libibumad is only an interface to the kernel umad module, where libibmad is more abstract. As far as moving ib_types, I suggested this a while back. http://www.mail-archive.com/gene...@lists.openfabrics.org/msg27439.html Let's see if I can summarize the thread. - Sean was workiong on libibacm and redefined ib_types.h definitions. - I suggested moving ib_types.h to umad so he would not have a dependancy on OpenSM. - Sean brought up that ib_types.h is large and probably should be split - I agreed, and asked Sasha if such a patch would be acceptable, or create a new library to deal with the inline functions in ib_types.h - Hal said that ibutils requires ib_types.h but does not want a dependancy on libibumad... - I suggested a separate library to solve this problem. - Hal corrected himself saying that ibutils requires osm_vendor_ibumad. However, OpenSM does not always use libibumad (depending on the underlying stack) so it would need to get ib_types somewhere else. Hal was also concerned about a library with little more than a header file in it. - Jason chimed in with "Please no more libraries"... :-) (and digressed with Sean in to PR queries, MPI, and other useful, but unrelated, stuff) - Sean says "libibumad is pretty useless without some network structure definitions." - I state that it looks like ibutils dependancy is on the static functions in ib_types.h only. - Hal says yes ibutils depends on OpenSM for the vendor layer and that Mellanox is better able to answer questions regarding ibutils support. - Hal says he thinks ib_types is "more akin to what is in libibmad rather than libibumad" - Sean finds that ib_types.h includes complib headers. - I submit a "rough hack" to remove complib headers. - Jason, Sean, and myself discuss ugly byteswapping functions. - Sasha agrees that he is not sure that umad is the right place for ib_types - Sean says we should split the file up and at least some of the definitions should be in umad... We all get busy... I think we need to move ib_types (mad definitions to umad). Basic MAD definitions should be provided at the lowest possible level so all software can use them. The issues (solutions) are: ib_types depends on complib at the moment (fixable) ibutils depends on OpenSM (it will anyway -- non-issue) somethings in ib_types are ugly, byteswapping (non-issue; deal with it later) OpenSM may _not_ include umad and therefore miss defines. (fixable?) As for this last item, would it be a big deal to require umad for the header only? Does umad not compile somewhere that other vendor layers are used? I think it is much better for OpenSM to require umad than for other MAD processing software to require OpenSM. Also, would splitting ib_types help this at all? Ira > > -- Hal > -- > 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://BLOCKEDvger.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
