On Tue, 19 Oct 2010 20:28:18 -0700 Jason Gunthorpe <[email protected]> wrote:
> On Tue, Oct 19, 2010 at 06:12:56PM -0700, Ira Weiny wrote: > > > I am all for "cleaner, more capable..." but why incompatible? If we want to > > start fresh and then convert OpenSM later, fine. But _don't_ forget to go > > back and convert OpenSM, because if you leave ib_types.h out there someone > > is > > going to use it and we are back to where we started... :-( Same for ibmad, > > when these definitions become available in umad, mad can be simplified. > > ib_types.h should not be installed in /usr/include, stop doing that > and that risk goes away. That is one way to solve it, but only after those definitions (or equivalent) are available in /usr/include. > > ibmad can't really be changed, it is system library with a defined > API. Maybe ibmad.2 or something, I don't know. I tried to use some of > the PR APIs in it, and I've found them not useful :( ibmad.2 is the way to go. I have expressed my distaste for ibmad in the past and I agree, it is too established to be changed. But I have not had the time. Mainly I am trying to support Sean who has the time. Ira > > For instance we can't just abandon the mad_get_fields approach because > we have real, usuable field access in umad, it has to stay. > > > Right now there are 3 headers I find path record in. > > > libibverbs: sa.h > > This isn't a MAD path record, this is the kernel version, which is > unpacked. What we really needs is MAD 2 kernel and vice versa > conversion in a library. I already have code that does this in > several places :( > > > libibmad: mad.h > > You mean mad_get_fields IB_SA_PR_DGID_F, etc? It doesn't even have all > the fields :( > > > opensm: ib_types.h > > Yep. > > > Node type is defined in: > > > > libibverbs: verbs.h > > opensm: ib_types.h > > libibmad: mad.h > > > > I could go on. > > Keep in mind that for the most part libibmad is someones attempt to > make a set of accessors and structures for mads. It is incomplete. It > is largely unusable. I certainly haven't been able to use its PR > structure parsing functions for any real app. Was it just pulled out > of opensm? I don't know, I'd just as soon see that part of it be > discarded, and a complete set of structures added to umad. > > opensm has unique problems because they want to remain independent of the > OFA stack, I don't think they have a choice but to duplicate. > > Jason -- Ira Weiny Math Programmer/Computer Scientist Lawrence Livermore National Lab 925-423-8008 [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
