<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [ofw] WDK build environment migration thoughts</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><?xml:namespace
prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff size=2>I've noticed unnecessary
changes in ib_bus.inf:</FONT></SPAN></o:p></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff
size=2> </FONT></SPAN></o:p></SPAN><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff size=2>branding changed from
OpenIB Alliance to Mellanox.</FONT></SPAN></o:p></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008></SPAN><SPAN class=905453612-01052008><FONT
color=#0000ff size=2> removed hardware IDs and device
descriptors for QLogic Fibre Channel and Ethernet bridge
modules.</FONT></SPAN></o:p></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff size=2>Rebranding is
also noticed in ib_srp.inf,
netipoib.inf</FONT></SPAN></o:p></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff
size=2></FONT></SPAN></o:p></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff
size=2>Thanks,</FONT></SPAN></o:p></SPAN></DIV>
<DIV dir=ltr align=left><SPAN
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p><SPAN
class=905453612-01052008><FONT color=#0000ff
size=2>Alex.</FONT></SPAN></o:p></SPAN></DIV></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> ofw-bounces@lists.openfabrics.org
[mailto:ofw-bounces@lists.openfabrics.org] <B>On Behalf Of </B>Alex
Naslednikov<BR><B>Sent:</B> Wednesday, April 30, 2008 4:20 AM<BR><B>To:</B>
Alex Naslednikov; Smith, Stan; Ishai Rabinovitz<BR><B>Cc:</B>
ofw@lists.openfabrics.org<BR><B>Subject:</B> RE: [ofw] WDK build environment
migration thoughts<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/rtf format -->
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff
size=2>Hello,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>I committed
our WDK and __ptr64 patch into WinOF trunk, and WinOF and WinIB trunks were
synchronized again.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>You can find
below some further explanations :</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>1. IBAL
compiles now with WDK6001.18001. According to Microsoft, it should be the last
and official release.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>We preserved
the backward compatibility with DDK, but some intermediate versions of WDK may
be incompatible</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>2. Please,
be aware that one has to change WinOF modules that aren't in WinIB stack (like
additional ulps : udapl, vnic etc.) according to new
methodology</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>Also, I'd
like to point your attention, that these modules will work as is on
homogeneous systems (x86, x64), but not on mixed systems (x86 application on
x64 kernel)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>In addition,
Microsoft fixed an internal compiler bug when compiling modules with long
(__ptr64) pointers on functions (occurred only in x86 CHECKED
environment).</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>So, you
should not have problem with compilation after adjusting
makefiles</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>3. This
revision contains:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2> 3.1.
All bugfixes from WinOF trunk, from rev. 939 to 1067</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2> 3.2.
Mellanox __ptr64 solution and WDK poring, starting from rev.
2164</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2> 3.3.
All bugfixes and patches from connectx branches (both Mellanox and
WinOF)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>It was a
large amount of code to be merged from 4 different svn trees (trunk and
connectx branch in WinOF, and trunk and connectx branch in
WinIB).</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>We will
appreciate your code review, just to be sure that we didn't forget to insert
any minor patch or bug fix.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff size=2>4. I
carefully tested new trunk inside Mellanox, on different platforms, both with
DDK and WDK compilers. Please, update us about every minor problem during your
testing.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#0000ff
size=2>Thanks,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Naslednikov Alexander
(a.k.a XaleX)</FONT></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Windows
Team</FONT></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Mellanox
Technologies </FONT></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Tahoma
size=1>_____________________________________________ </FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma size=1>From:
</FONT></B> <FONT face=Tahoma size=1>Alex Naslednikov
</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Sent: </FONT></B> <FONT face=Tahoma size=1>Monday, April 21,
2008 7:15 PM</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>To: </FONT></B> <FONT face=Tahoma size=1>Alex
Naslednikov; 'Smith, Stan'; Ishai Rabinovitz</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Cc: </FONT></B> <FONT face=Tahoma
size=1>'ofw@lists.openfabrics.org'</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Subject: </FONT></B> <FONT
face=Tahoma size=1>RE: [ofw] WDK build environment migration
thoughts</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Hi all,<BR>I would like to
repost my previous message, because I haven't received yet your
comments.<BR>Our regression seems to be stable, so we are going to commit the
change into WinOF trunk the nearest time.<BR>For you convenience, I also
provide some typical changes as a patch (attached to this mail). Please, read
the explanation below before - it will help you a lot.<BR>Be aware that all
the modules not contained in Mellanox WinIB stack (like udapl, vnic) should be
also changed according to this methodology.<BR><BR>It is very large change, so
I'll appreciate your time and effort while reviewing the methodology and the
patch itself.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>Thanks,<BR></FONT><BR><B></B><B><FONT
face="Times New Roman">Naslednikov Alexander (a.k.a XaleX)<BR>Windows
Team<BR>Mellanox Technologies<BR></FONT></B></SPAN></P><BR>
<P dir=ltr><SPAN lang=en-us><FONT face=Tahoma
size=1>_____________________________________________ </FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma size=1>From:
</FONT></B> <FONT face=Tahoma size=1>Alex Naslednikov
</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Sent: </FONT></B> <FONT face=Tahoma size=1>Thursday, April
10, 2008 4:09 PM</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>To: </FONT></B> <FONT face=Tahoma size=1>'Smith,
Stan'; Ishai Rabinovitz</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Cc: </FONT></B> <FONT face=Tahoma
size=1>ofw@lists.openfabrics.org</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Tahoma
size=1>Subject: </FONT></B> <FONT
face=Tahoma size=1>RE: [ofw] WDK build environment migration
thoughts</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Hi all,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>It's a good idea to
clarify some points before announcing Mellanox patch for WDK porting and
__ptr64 problems.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Hope, these explanations
will be informative enough and not so long.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><U><B><FONT face=Arial size=2>1. __ptr64
problem</FONT></B></U><B></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Briefly speaking, this
problem arises when copying 32bit len pointer into 64bit len pointer. In this
case,</FONT><U> <FONT face=Arial size=2>signed pointer extension</FONT></U>
<FONT face=Arial size=2>will take place.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>How it's applicable to
WinOF ? A lot of pointer were declared to be __ptr64 (i.e., to be always
"long", even in 32bit kernel systems), that's to preserve on unique size of
structs used in IOCTL calls. The main problem it will cause is between
32bit user applications and 64bit kernel application.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>When user code do
operation like </FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>s_ptr =
&my_struct;</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>my_type* __ptr64 ptr =
s_ptr;</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Than kernel will receive
ptr with invalid upper bits data (4 bytes FF).</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>To avoid signed pointer
extension, PtrToPtr64() function should be used.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Also, I found some other
places where dangerous signed pointer extension took place, even on 32bit
kernel.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Yet another problem that
arises with __ptr64 attribute is internal compiler error (C1001) in WDK
when using __ptr64 pointer to function (callback)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>This problem was described
in ofw discussion, you can see also :</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us></SPAN><A
href="http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx"><SPAN
lang=en-us><U><FONT face=Arial color=#0000ff
size=2>http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx</FONT></U></SPAN></A><SPAN
lang=en-us></SPAN></P>
<P dir=ltr><SPAN lang=en-us></SPAN><A
href="http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html"><SPAN
lang=en-us><U><FONT face=Arial color=#0000ff
size=2>http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html</FONT></U></SPAN></A><SPAN
lang=en-us><FONT face=Arial size=2> (posted by Jan from OFW)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Our
solution:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>1. Initially, we decided
to remove all __ptr64 attributes except those ones inside IOCTL structures.
After, put PtrToPtr64() conversion on every assignment to long
pointer.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>(like my_type* __ptr64 ptr
= PtrToPtr64(s_ptr); )</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>During this solution, we
changed a huge amount of code, so patch became unreadable. And it was
difficult to validate that all long pointer (with __ptr64 attribute) were used
in a proper manner</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>2. So, we decided about
another solution:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> All __ptr64
occurrences were replaced by either:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> i) TO_LONG_PTR(type,
field) macro, when occurred inside structure</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>ii) VOID_PTR64 macro
otherwise (defined as void macro)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>#define CONCAT(str1, str2)
str1##str2</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>#define
TO_LONG_PTR(type,member_name) \</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> union {
type member_name; uint64_t CONCAT(member_name,_padding) ;
}</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Thus, we can both preserve
on a uniform shapes of structs in user and kernel and to avoid unsafe pointer
arithmetic !</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>The patch now is much more
readable, but it sill consist of thousands lines.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><U><B><FONT face=Arial size=2>2. Migration to
WDK</FONT></B></U><B></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Main issue here was to
preserve on backward compatibility with DDK</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>We were able to compile
our stack with WDK, while the main problems we found were :</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>1. WDK uses newer version
of SDK (SDK Vista). So, when using 2 or more versions of SDK on the same build
machine, one has to update </FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>PLATFORM_SDK_PATH variable
to point on the proper version of SDK (for example,
PLATFORM_SDK_PATH=%sysdrive%:\PROGRA~1\MI2578~1\windows\v6.1)</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>2.verify.src script in WDK
(new add-on) checks if your SOURCES file is in appropriate
format.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>For example, you can't set
implicitly path to system .dll in TARGETLIBS, but to use
USE_<MODULE_NAME> =1 macro</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Example:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Old code :
</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2> ....</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>TARGETLIBS=
\</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
$(CRT_LIB_PATH)\msvcprt.lib\</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
$(SDK_LIB_PATH)\Ws2_32.lib\</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
$(TARGETPATH)\*\mtcr.lib</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2></FONT></SPAN> </P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>New code
:</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>USE_MSVCRT=1</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>USE_NTDLL=1</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2></FONT></SPAN> </P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>TARGETLIBS=
\</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
$(SDK_LIB_PATH)\Ws2_32.lib\</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
$(TARGETPATH)\*\mtcr.lib</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>3. Some other problems,
like mulitple includes error in .rc files, or problem with substituing more
than one symbol constant into string in Makefiles (some version of
WDK)</FONT></SPAN></P><BR>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Currently, we continue
testing and will advertise these patches right after the testing will
finish</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Naslednikov Alexander
(a.k.a XaleX)</FONT></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Windows
Team</FONT></B></SPAN></P>
<P dir=ltr><SPAN lang=en-us><B><FONT face=Arial size=2>Mellanox
Technologies</FONT></B> </SPAN></P><BR>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>-----Original
Message-----</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>From:
ofw-bounces@lists.openfabrics.org [</FONT></SPAN><A
href="mailto:ofw-bounces@lists.openfabrics.org"><SPAN lang=en-us><U><FONT
face=Arial color=#0000ff
size=2>mailto:ofw-bounces@lists.openfabrics.org</FONT></U></SPAN></A><SPAN
lang=en-us><FONT face=Arial size=2>] On Behalf Of Smith,
Stan</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Sent: Tuesday, April 08,
2008 4:10 PM</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>To: Ishai
Rabinovitz</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Cc:
ofw@lists.openfabrics.org</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Subject: [ofw] WDK build
environment migration thoughts</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Hello,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> I strongly believe
it would help the WinOF community in transitioning to the WDK build
environment if the connectX branch</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>(svn:gen1\branches\ConnectX) was used as a WDK build environment
staging grounds prior to merging the WDK modifications into the mainline
trunk.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>This has been talked about
before although it still (as of last Friday) does not build using the latest
WDK version.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2></FONT></SPAN> </P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>One week prior to merging
the WDK fixes into the mainline trunk, if you were to push all the WDK fixes
into the ConnectX branch and then advertise on the ofw mailing list the
availability of a WDK build branch along with</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> 1) how to build in
the WDK environment,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
which version of the WDK is required + a URL link where to get the
WDK.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> 2) An explanation
of why and how the __ptr64 attributes were removed along with
how</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>
others should correct their codes containing __ptr64
attributes.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2> 3) updates to the
WinOF wiki page describing how to build in the WDK env.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Let this branch exist for
one week, receiving feedback from the list and then merge into the mainline
trunk.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Using this approach is
certainly community friendly and may prevent developer
surprises.</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>ConnectX branch
availability dates plus when the actual WDK fixes would be merged into the
mainline trunk would be published beforehand.</FONT></SPAN></P><BR>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Thanks for your
consideration,</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>Stan.</FONT></SPAN></P><BR><BR>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>_______________________________________________</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>ofw mailing
list</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us><FONT face=Arial
size=2>ofw@lists.openfabrics.org</FONT></SPAN></P>
<P dir=ltr><SPAN lang=en-us></SPAN><A
href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw"><SPAN
lang=en-us><U><FONT face=Arial color=#0000ff
size=2>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</FONT></U></SPAN></A><SPAN
lang=en-us></SPAN></P></BLOCKQUOTE></BODY></HTML>