[Openib-windows] ib_types.h and Win/Linux consolidation

[Fabian Tillier]

On 06 Jul 2006 15:03:02 -0400, Hal Rosenstock <halr at voltaire.com> wrote:
> Hi Eitan,
>
> On Thu, 2006-07-06 at 14:11, Eitan Zahavi wrote:
> > Hi All,
> >
> > I have been approached by several people asking for where does one
> > gets a header
> >
> > file defining the IBTA "wire" protocol.
> >
> > My response was: "Ohh we got it all coded in
> > osm/include/iba/ib_types.h".
>
> Actually I was thinking the opposite: that this file was way too big and
> should be broken up into smaller more manageable pieces.
>
> In this usage, I think all is referring to all MADs. ib_types.h supports
> SM and SA MADs and some other MADs but not all MADs.
>
> > "But that thing is so down the tree I do not consider as official" was
> > the answer.
>
> It is currently used by management and utils. utils/linux-user could be
> moved.
>
> What would be the new proposed location for this ?
>
> > So the point is clear: If we are missing such a complete IBTA H file
> > and people are actually looking for where the wire protocol is being
> > defined why shouldn't we promote ib_types.h to the main include
> > directory?
> >
> > Another issue with ib_types.h :
> >
> > Apparently the WinIB (OpenIB windows) version and the Linux version
> > are a little different.
> >
> > Major changes are that the Windows version is a spec 1.1 compliant and
> > the Linux is supporting version 1.2.
>
> Why is Windows 1.1 and not 1.2 compliant ?

I'm not sure what the deficiencies are here - Windows doesn't have SRQ
support, or IB 1.2 FMR support, but other than that the on-wire MAD
stuff should all be fine.

What's missing?

> > Another difference is the fact some "verbs" or core oriented
> > definitions found their way into the WinIB version.
>
> Another issue is that ib_types.h requires some complib things too.
>
> > I hope we can clean those up and have a merged version in place.
>
> Perhaps but is this a real requirement ?

I think that it would be a mistake to share a file like this between
Windows and Linux, as that requires some sort of abstraction for types
and packing.  Since abstractions like this won't fly in LKML, it would
become the burden of the Windows stack to try to get things to be
portable.  I don't support such an uneven burden being placed on me.

- Fab