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. 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 :( 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 -- 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
