ib_types.h moving [was: Re: [ofa-general] [RFC] 3/5: IB ACM: libibacm]

[Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html