On 13:20 Thu 17 Sep , Ira Weiny wrote: > > Sasha, would you be willing to accept such a patch? First move ib_types.h to > umad and then move the long inline functions into the lib and separate out > the remaining header. > > Or would you prefer a new library? I think there is enough code there but I > leave it up to you.
Basically cleaning ib_types.h issue (which was raised repeatedly in the past too) and making some order here with libibmad duplications would be a nice thing. However I still not understand clearly yet how things should be organized properly (assumig all histories, ibutils dependencies, etc.). And sure we can try to find an optimal model, so let's discuss: libibumad is an option. However today this library only provides a layer to user_mad kernel API and actually is transparent to MAD's structure. Maybe complicating this with adding ib_types.h and some MAD fields access helpers is not a big deal, but sort of disadvantage anyway. To place this stuff in separate library/package is another possibility, but perspective of adding new package doesn't make me happy. In theory ib_types.h would be also merged with libibmad. However for me the current libibmad seems to be too much heavy for not using it for stuff other than infiniband-diags. Another options? Now I likely would agree with Ira that moving ib_types.h to libibumad is a least painful option. Do we have a better ideas? Sasha _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
