[ofw] RE: ib_types.h moving

[Sean Hefty]

>So far I can only think of 2 "correct" options.
>
>   1) Make ib_types.h into a new library and have libibverbs, libibmad,
>      opensm, and MPI's use the constants and helper functions there.  This of
>      course would force some dependencies.
>
>   2) split up and spread ib_types.h around to appropriate places.  This will
>      likely include libibmad and libibverbs (others?) I don't think libibumad
>      is appropriate really.  At first, I suggested this mainly out of
>      convenience because WinOF uses it.  However, I don't think it is
>      architecturally correct.  libibumad looks to have a sound interface and
>      should not be messed with.

The only issue that was pointed out was that the IB ACM duplicated some network
structure definitions (the SA MAD format, McMemberRecord, PathRecord).  It seems
perfectly natural to me to have the library that allows you to send and receive
MADs to provide these definitions, especially considering how fundamental these
specific attributes are to using IB.  Even though umad_send and umad_recv are
both defined to take a void * input buffer, they expect a specific format to
that buffer.

libibverbs defines host structure definitions for McMemberRecord and PathRecord,
but doesn't use them.  This allows the rdma_cm and ib_cm to remain independent,
but use the same definition.

IB ACM is coded to libibumad directly, mainly because I didn't see any benefit
to coding to a higher level MAD interface that was more complex to use.  Trying
to keep the defines in a higher level library, which is what we have now, either
results in duplicating them or forcing a dependency where there wouldn't be any.

And to be clear, I'm only referring to definitions in ib_types.h (and some in
mad.h), and not any actual functionality.

- Sean