Hi Fab, On Thu, 2006-07-06 at 15:22, Fabian Tillier wrote: > On 06 Jul 2006 15:03:02 -0400, Hal Rosenstock <[EMAIL PROTECTED]> 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,
Linux doesn't have real 1.2 FMR support either. > but other than that the on-wire MAD > stuff should all be fine. > > What's missing? I'm not familiar with the Windows support so can't comment on the specifics. Eitan ? > > > 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, This is not an LKML file. It's a userspace file. > 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. I'm neither for or against this as I do not understand what this means (e.g. what are the specific changes). In the past, Windows changes have been rolled back into the Linux user support for OpenSM. However, I am also wary of any "baggage" here which limits what can be done. As I have stated before, IMO OpenIB OpenSM is currently accomodating Windows as opposed to it being a firm requirement that it be supported. I would prefer the two not to fork but if OpenSM on Linux is impaired for some reason a split might be necessary. One area where there has been difficulty in this in the past has been the direct use of pthreads versus the threading API in complib. -- Hal > - Fab _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
