<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [ofw] WDK build environment migration thoughts</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I would like to thank all of you personally for reviewing my commit!</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I received a lot of emails, so I would like to put here some order and answer them all in one mail.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Also, a lot of questions had been already answered in my previous e-mails. For you convenience, I will answer them all again</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q1. I still didn't understand why we need this commit and which problem it solves?</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Before this commit, we had several main problems:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 1. 32/64 compatibility problem</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 2. Problem with signed extension of __ptr64 fields. This problem is relevant also to 64/64 systems, not only to 32/64</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 3. Earlier versions of WDK had problem to compile code with __ptr64 pointer to functions in x86 CHK version (</FONT><FONT FACE="Times New Roman">AL_API * __ptr64 ib_pfn_xxx)</FONT><FONT SIZE=2 FACE="Arial">. This problem was promised to be fixed in WDK6001.18001, but 2 months ago before we couldn't assume this.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 4. WDK porting</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">For more information, please read </FONT></SPAN><A HREF="http://lists.openfabrics.org/pipermail/ofw/2008-April/002307.html"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">http://lists.openfabrics.org/pipermail/ofw/2008-April/002307.html</FONT></U></SPAN></A><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">This post explains in details this issue and several related issues.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q2. It sounds like the __ptr64 patch failed to meet its objective if 32/64 support is broken. Just deleting the __ptr64 attribute would have accomplished the same end result and been ‘cleaner’.</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Definitely not! __ptr64 and WDK migration patch comes to solve this problem! We have very limited time to fully test it on mixed (32/64) systems, but a lot of tests that failed before pass now. Of course, it may still contains bugs (one major bug have been found by Fab and I already fixed it).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Main issue here is that we removed all __ptr64 appearances, but still preserved on a unique shape of all IOCTL structures using TO_LONG_PTR macro, thus solving the problem with signed pointer extension.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q3. Why can’t we use PtrToPtr64() macro that solves the problem of signed pointer extension?</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">(See related links from </FONT></SPAN><A HREF="http://lists.openfabrics.org/pipermail/ofw/2008-April/002307.html"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">http://lists.openfabrics.org/pipermail/ofw/2008-April/002307.html</FONT></U></SPAN></A><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> and first paragraph explanations as well)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Yes, it indeed solves it</FONT> <FONT SIZE=2 FACE="Wingdings">J</FONT><FONT SIZE=2 FACE="Arial">. And our initial solution used this technique. </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">But this solution has it own limitations. First of all, consider what should you do?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">At a first glance, it looks pretty simple: remove all __ptr64 except of ioctl structures, then find out all places were unsafe (signed) pointer conversion can take place, and put there PtrToPtr64().</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">But if you have struct inside struct inside ioctl struct (real case), you should pass them all manually and verify that all use of __ptr64 pointer are “safe”, or put there PtrToPtr64().</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Finally, I wasted a lot of time and efforts to MANUALLY find these places and patch that I got contained 10K lines. I am not sure somebody can do code review for it, and there’s still a good possibility for bugs, cause changes were done manually.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Our current solution is much better because it based on automatic changes, much more readable and it will be much easier to debug it afterwards.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q4. I can’t understand why we need 4 different names for *PTR64 macro? </FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q5. Let’s remove all void *PTR64 macro</FONT></B><FONT SIZE=2 FACE="Arial">!</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">It’s a key idea of our solution</FONT> <FONT SIZE=2 FACE="Wingdings">J</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">TO_LONG_PTR macro comes to replace __ptr64 inside ioctls.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">The rest of macros were defined according to place where __ptr64 had been removed.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">FUNC_PTR64 – inside function signature</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">VOID_PTR64 – inside raw code</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">STRUCT_PTR64 – inside struct that is know (for sure) it is not used inside ioctls</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Etc.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">These temporarily macros will be removed in the next release (or even after). Now, I’d like to preserve them for the case of debug: one can easily redefine them back to __ptr64 or just compare to old code. Please, do not remove this now!</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q6. The __ptr64 sign extension happened with the DDK too – so why is it suddenly an issue? Is it because 32-bit apps running on a 64-bit OS get a lot of pointers with the MSb set?</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Yep. And not only this! When trying our first solution (with PtrToPtr64 macro), I found several cases were long __ptr64 pointer got values from 32bit len pointers and handles. Now it’s not the case.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q7. Rebranding. Why some *.inf files were changed?</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Sorry, guys, it was a merge problem. I will send patch in a separate mail</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Q8. I wrote in my previous mail:</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Also, I'd like to point your attention,</FONT><B> <FONT SIZE=2 FACE="Arial">that these modules [UDAPL2, VNIC] will work as is on homogeneous systems (x86, x64), but not on mixed systems</FONT></B><FONT SIZE=2 FACE="Arial"> (x86 application on x64 kernel)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">So, you should not have problem with compilation after adjusting makefiles</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Some people understood that current patch doesn’t support 32/64 systems. </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I just wanted to say that UDAPL2, VNIC and other modules that are not in WinIB stack were not patched. But they should work in 32/32 and 64/64, after appropriate changes in Makefiles.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">More to come.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">XaleX</FONT></SPAN></P>
<BR>
<BR>
<BR>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=1 FACE="Tahoma">_____________________________________________ </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">From: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Alex Naslednikov </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Sent: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Wednesday, April 30, 2008 10:20 AM</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">To: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Alex Naslednikov; 'Smith, Stan'; Ishai Rabinovitz</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Cc: </FONT></B> <FONT SIZE=1 FACE="Tahoma">'ofw@lists.openfabrics.org'</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Subject: </FONT></B> <FONT SIZE=1 FACE="Tahoma">RE: [ofw] WDK build environment migration thoughts</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hello,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">You can find below some further explanations :</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">So, you should not have problem with compilation after adjusting makefiles</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">3. This revision contains:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"> 3.1. All bugfixes from WinOF trunk, from rev. 939 to 1067</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"> 3.2. Mellanox __ptr64 solution and WDK poring, starting from rev. 2164</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"> 3.3. All bugfixes and patches from connectx branches (both Mellanox and WinOF)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">Thanks,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Naslednikov Alexander (a.k.a XaleX)</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Windows Team</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Mellanox Technologies </FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=1 FACE="Tahoma">_____________________________________________ </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">From: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Alex Naslednikov </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Sent: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Monday, April 21, 2008 7:15 PM</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">To: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Alex Naslednikov; 'Smith, Stan'; Ishai Rabinovitz</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Cc: </FONT></B> <FONT SIZE=1 FACE="Tahoma">'ofw@lists.openfabrics.org'</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Subject: </FONT></B> <FONT SIZE=1 FACE="Tahoma">RE: [ofw] WDK build environment migration thoughts</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=1 FACE="Tahoma">_____________________________________________ </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">From: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Alex Naslednikov </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Sent: </FONT></B> <FONT SIZE=1 FACE="Tahoma">Thursday, April 10, 2008 4:09 PM</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">To: </FONT></B> <FONT SIZE=1 FACE="Tahoma">'Smith, Stan'; Ishai Rabinovitz</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Cc: </FONT></B> <FONT SIZE=1 FACE="Tahoma">ofw@lists.openfabrics.org</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=1 FACE="Tahoma">Subject: </FONT></B> <FONT SIZE=1 FACE="Tahoma">RE: [ofw] WDK build environment migration thoughts</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Hi all,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Hope, these explanations will be informative enough and not so long.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><U><B><FONT SIZE=2 FACE="Arial">1. __ptr64 problem</FONT></B></U><B></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Briefly speaking, this problem arises when copying 32bit len pointer into 64bit len pointer. In this case,</FONT><U> <FONT SIZE=2 FACE="Arial">signed pointer extension</FONT></U> <FONT SIZE=2 FACE="Arial">will take place.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">When user code do operation like </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">s_ptr = &my_struct;</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">my_type* __ptr64 ptr = s_ptr;</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Than kernel will receive ptr with invalid upper bits data (4 bytes FF).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">To avoid signed pointer extension, PtrToPtr64() function should be used.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html</FONT></U></SPAN></A><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (posted by Jan from OFW)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Our solution:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">(like my_type* __ptr64 ptr = PtrToPtr64(s_ptr); )</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">2. So, we decided about another solution:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> All __ptr64 occurrences were replaced by either:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> i) TO_LONG_PTR(type, field) macro, when occurred inside structure</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ii) VOID_PTR64 macro otherwise (defined as void macro)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">#define CONCAT(str1, str2) str1##str2</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">#define TO_LONG_PTR(type,member_name) \</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> union { type member_name; uint64_t CONCAT(member_name,_padding) ; }</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">2. Migration to WDK</FONT></B></U><B></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Main issue here was to preserve on backward compatibility with DDK</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Example:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Old code : </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> ....</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">TARGETLIBS= \</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> $(CRT_LIB_PATH)\msvcprt.lib\</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> $(SDK_LIB_PATH)\Ws2_32.lib\</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> $(TARGETPATH)\*\mtcr.lib</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">New code :</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">USE_MSVCRT=1</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">USE_NTDLL=1</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">TARGETLIBS= \</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> $(SDK_LIB_PATH)\Ws2_32.lib\</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> $(TARGETPATH)\*\mtcr.lib</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Naslednikov Alexander (a.k.a XaleX)</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Windows Team</FONT></B></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><B><FONT SIZE=2 FACE="Arial">Mellanox Technologies</FONT></B> </SPAN></P>
<BR>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">-----Original Message-----</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">From: ofw-bounces@lists.openfabrics.org [</FONT></SPAN><A HREF="mailto:ofw-bounces@lists.openfabrics.org"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">mailto:ofw-bounces@lists.openfabrics.org</FONT></U></SPAN></A><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">] On Behalf Of Smith, Stan</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Sent: Tuesday, April 08, 2008 4:10 PM</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">To: Ishai Rabinovitz</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Cc: ofw@lists.openfabrics.org</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Subject: [ofw] WDK build environment migration thoughts</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Hello,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 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 SIZE=2 FACE="Arial">(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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial"> </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial"> 1) how to build in the WDK environment,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 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 SIZE=2 FACE="Arial"> 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 SIZE=2 FACE="Arial"> others should correct their codes containing __ptr64 attributes.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 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 SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Using this approach is certainly community friendly and may prevent developer surprises.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 SIZE=2 FACE="Arial">Thanks for your consideration,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Stan.</FONT></SPAN></P>
<BR>
<BR>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">_______________________________________________</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ofw mailing list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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 COLOR="#0000FF" SIZE=2 FACE="Arial">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</FONT></U></SPAN></A><SPAN LANG="en-us"></SPAN></P>
</BODY>
</HTML>