[ofw] RE: porting IB management code to Windows

[Sean Hefty]

>Hold the presses - there is an absolute requirement that any part of a WinOF
>release builds using the WDK build environment!

Why is this an absolute requirement for userspace applications? 

ND is provided as a binary component that is built using some unknown build
environment.  The source code is not available.  It has a different license.
But it still ships with WinOF.  Building in the WDK is a political decision, not
a technical one.

At the extremes, the IB management maintainers can refuse to support Windows
because they don't like the changes to build using the MS WDK compiler.  Or,
WinOF can refuse to ship IB management utilities because it builds differently.
Obviously no one benefits from taking these extreme stances.

There are real benefits to maintaining a single source code base.  I would guess
between 10-25 patches are added to the management tree each week, many, if not
most, by developers that only care about Linux.  The Windows stack gains a lot
by being able to take advantage of those changes.  (Note that most patches are
against opensm.  If we limit the current discussion to only the diags and
libibmad, we're looking at roughly 12,000 lines of code and probably about 5
patches per week.)

I posted a patch to show the changes necessary to build in the WDK environment.
Jason asked, "Is there any way it would be acceptable to use gcc (or even the
Intel compiler) as the mandatory Windows C compiler?"  And Sasha's commented, "I
would prefer to minimize amount of needed changes and would really prefer to not
get a lot of limitations in using modern C."  My reply was "I personally have no
issue with using a different compiler, but the WWG would need to decide on that
sort of change."

I looked into the issue.  The compiler that ships with the WDK does not support
c99 to the extent needed.  Because using the Intel compiler was convenient for
me, I tested with that and was eventually able to reduce the necessary code
changes.  I built in the WDK build environment.

At this point, I see the following options:

1. Fork the code:
The benefits or requirement of building within the existing Windows build
environment is greater or more important than maintaining a single source code
base.
2. Accept the changes as posted:
If the benefits or requirement of building within the existing Windows build
environment is greater or more important than allowing c99 constructs, but not
at the cost of forking the code.
3. Build the IB management with a different compiler:
The benefits of support c99 is greater than the benefits of building within the
existing Windows build environment. 

If there's another solution here, I'm open to ideas.  Of these three, I prefer
option 2 or 3.  Option 3 means slightly more work for me because it requires
making binaries available, but there are real benefits to supporting c99.

- Sean