<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:v = 
"urn:schemas-microsoft-com:vml"><HEAD><TITLE>RE: [ofw] WDK build environment migration thoughts</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>@font-face {
        font-family: Cambria Math;
}
@font-face {
        font-family: Calibri;
}
@font-face {
        font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
        COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
        COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
        FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
        FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
        page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
<META content="MSHTML 6.00.5730.13" name=GENERATOR></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff 
size=2>Please, disregard my previous mail.</FONT></SPAN></DIV>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff 
size=2>Attached there is a correct patch</FONT></SPAN></DIV>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff 
size=2>--</FONT></SPAN></DIV>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff 
size=2>[PTR64] Explicitly casting from uint64_t to pointer in order to avoid 
warning C4305.<BR>Macro CONCAT renamed to IB_CONCAT<BR>Signed-off by: 
XaleX</FONT></SPAN></DIV>
<DIV><SPAN class=348050814-05052008><FONT face=Arial color=#0000ff size=2>Index: 
ulp/opensm/user/include/iba/ib_types.h<BR>===================================================================<BR>--- 
ulp/opensm/user/include/iba/ib_types.h (revision 2386)<BR>+++ 
ulp/opensm/user/include/iba/ib_types.h (revision 2388)<BR>@@ -81,10 +81,10 
@@<BR> #define STRUCT_PTR64<BR> #endif<BR> <BR>-#define 
CONCAT(str1, str2) str1##str2<BR>+#define IB_CONCAT(str1, str2) 
str1##str2<BR> <BR> #define TO_LONG_PTR(type,member_name) 
\<BR>-    union { type member_name;  uint64_t 
CONCAT(member_name,_padding) ; }<BR>+    union { type 
member_name;  uint64_t IB_CONCAT(member_name,_padding) ; 
}<BR> <BR> <BR> <BR>Index: 
ulp/opensm/user/include/iba/ib_types_extended.h<BR>===================================================================<BR>--- 
ulp/opensm/user/include/iba/ib_types_extended.h (revision 2386)<BR>+++ 
ulp/opensm/user/include/iba/ib_types_extended.h (revision 2388)<BR>@@ 
-57,32 +57,6 @@<BR>  #define 
__ptr64<BR> #endif<BR> <BR>-#ifndef FUNC_PTR64<BR>-#define 
FUNC_PTR64<BR>-#endif<BR>-<BR>-#ifndef TYPEDEF_PTR64<BR>-#define 
TYPEDEF_PTR64<BR>-#endif<BR>-<BR>-#ifndef VOID_PTR64<BR>-#define 
VOID_PTR64<BR>-#endif<BR>-<BR>-#ifndef STRUCT_PTR64<BR>-#define 
STRUCT_PTR64<BR>-#endif<BR>-<BR>-<BR>-//#ifndef CONCAT<BR>-#define CONCAT(str1, 
str2) str1##str2<BR>-//#endif<BR>-<BR>-//#ifndef T0_LONG_PTR<BR>-#define 
TO_LONG_PTR(type,member_name) \<BR>-    union { type 
member_name;  uint64_t CONCAT(member_name,_padding) ; 
}<BR>-//#endif<BR>-<BR> /*<BR>  * Defines the size of user 
available data in communication management MADs<BR>  */<BR>Index: 
ulp/sdp/include/SdpShared.h<BR>===================================================================<BR>--- 
ulp/sdp/include/SdpShared.h (revision 2386)<BR>+++ 
ulp/sdp/include/SdpShared.h (revision 2388)<BR>@@ -67,13 +67,13 
@@<BR> #define IOCTL_WSP_CLOSE_SOCKET  CTL_CODE(FILE_DEVICE_UNKNOWN, 
0x811, METHOD_BUFFERED ,FILE_ANY_ACCESS)<BR> #define 
IOCTL_WSP_USER_THREAD   CTL_CODE(FILE_DEVICE_UNKNOWN, 0x812, 
METHOD_BUFFERED ,FILE_ANY_ACCESS)<BR> <BR>-#ifndef CONCAT<BR>-#define 
CONCAT(str1, str2) str1##str2<BR>+#ifndef IB_CONCAT<BR>+#define IB_CONCAT(str1, 
str2) str1##str2<BR> #endif<BR> <BR> #ifndef 
TO_LONG_PTR<BR> #define TO_LONG_PTR(type,member_name) 
\<BR>-    union { type member_name;  uint64_t 
CONCAT(member_name,_padding) ; } ;<BR>+    union { type 
member_name;  uint64_t IB_CONCAT(member_name,_padding) ; } 
;<BR> #endif<BR> <BR> // Data structures that are used for 
connect<BR>Index: 
ulp/wsd/user/ibsp_iblow.c<BR>===================================================================<BR>--- 
ulp/wsd/user/ibsp_iblow.c (revision 2386)<BR>+++ 
ulp/wsd/user/ibsp_iblow.c (revision 2388)<BR>@@ -66,8 +66,8 
@@<BR> <BR>  IBSP_ENTER( IBSP_DBG_IO );<BR> <BR>- wr = 
(struct _wr * VOID_PTR64)wc->wr_id;<BR>- p_recv_wr = (struct _recv_wr * 
VOID_PTR64)wc->wr_id;<BR>+ wr = (struct _wr * 
VOID_PTR64)HDL_TO_PTR(wc->wr_id);<BR>+ p_recv_wr = (struct _recv_wr * 
VOID_PTR64)HDL_TO_PTR(wc->wr_id);<BR> <BR>  CL_ASSERT( wr 
);<BR> <BR>Index: 
core/al/kernel/al_proxy_verbs.c<BR>===================================================================<BR>--- 
core/al/kernel/al_proxy_verbs.c (revision 2386)<BR>+++ 
core/al/kernel/al_proxy_verbs.c (revision 2388)<BR>@@ -352,7 +352,7 
@@<BR>  cb_info.rec_type = CA_ERROR_REC;<BR>  /* Return the 
Proxy's open_ca handle and the user's context 
*/<BR>  cb_info.ioctl_rec.event_rec = 
*p_err_rec;<BR>- cb_info.ioctl_rec.event_rec.handle.h_ca = (ib_ca_handle_t 
VOID_PTR64)h_ca->obj.hdl;<BR>+ cb_info.ioctl_rec.event_rec.handle.h_ca = 
(ib_ca_handle_t 
VOID_PTR64)HDL_TO_PTR(h_ca->obj.hdl);<BR> <BR>  /* The proxy 
handle must be valid now. */<BR>  if( !h_ca->obj.hdl_valid )<BR>@@ 
-987,7 +987,7 @@<BR>  cb_info.rec_type = 
SRQ_ERROR_REC;<BR>  /* Return the Proxy's SRQ handle and the user's 
context */<BR>  cb_info.ioctl_rec.event_rec = 
*p_err_rec;<BR>- cb_info.ioctl_rec.event_rec.handle.h_srq = 
(ib_srq_handle_t 
VOID_PTR64)h_srq->obj.hdl;<BR>+ cb_info.ioctl_rec.event_rec.handle.h_srq 
= (ib_srq_handle_t VOID_PTR64) 
HDL_TO_PTR(h_srq->obj.hdl);<BR> <BR>  /* The proxy handle must 
be valid now. */<BR>  if( !h_srq->obj.hdl_valid )<BR>@@ -1291,7 
+1291,7 @@<BR>  cb_info.rec_type = QP_ERROR_REC;<BR>  /* 
Return the Proxy's QP handle and the user's context 
*/<BR>  cb_info.ioctl_rec.event_rec = 
*p_err_rec;<BR>- cb_info.ioctl_rec.event_rec.handle.h_qp = (ib_qp_handle_t 
VOID_PTR64)h_qp->obj.hdl;<BR>+ cb_info.ioctl_rec.event_rec.handle.h_qp = 
(ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(h_qp->obj.hdl);<BR> <BR>  /* The proxy 
handle must be valid now. */<BR>  if( !h_qp->obj.hdl_valid )<BR>@@ 
-1491,7 +1491,7 @@<BR>   if( p_ioctl->out.attr.h_pd 
)<BR>   {<BR>    p_ioctl->out.attr.h_pd 
=<BR>-    (ib_pd_handle_t 
VOID_PTR64)p_ioctl->out.attr.h_pd->obj.hdl;<BR>+    (ib_pd_handle_t 
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_pd->obj.hdl);<BR>   }<BR>   else<BR>   {<BR>@@ 
-1500,7 +1500,7 @@<BR>   if( p_ioctl->out.attr.h_sq_cq 
)<BR>   {<BR>    p_ioctl->out.attr.h_sq_cq 
=<BR>-    (ib_cq_handle_t 
VOID_PTR64)p_ioctl->out.attr.h_sq_cq->obj.hdl;<BR>+    (ib_cq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_sq_cq->obj.hdl);<BR>   }<BR>   else<BR>   {<BR>@@ 
-1509,7 +1509,7 @@<BR>   if( p_ioctl->out.attr.h_rq_cq 
)<BR>   {<BR>    p_ioctl->out.attr.h_rq_cq 
=<BR>-    (ib_cq_handle_t 
VOID_PTR64)p_ioctl->out.attr.h_rq_cq->obj.hdl;<BR>+    (ib_cq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_rq_cq->obj.hdl);<BR>   }<BR>   else<BR>   {<BR>@@ 
-1518,7 +1518,7 @@<BR>   if( p_ioctl->out.attr.h_srq 
)<BR>   {<BR>    p_ioctl->out.attr.h_srq 
=<BR>-    (ib_srq_handle_t 
VOID_PTR64)p_ioctl->out.attr.h_srq->obj.hdl;<BR>+    (ib_srq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_srq->obj.hdl);<BR>   }<BR>   else<BR>   {<BR>@@ 
-2063,7 +2063,7 @@<BR>  cb_info.rec_type = 
CQ_ERROR_REC;<BR>  /* Return the Proxy's cq handle and the user's 
context */<BR>  cb_info.ioctl_rec.event_rec = 
*p_err_rec;<BR>- cb_info.ioctl_rec.event_rec.handle.h_cq = (ib_cq_handle_t 
VOID_PTR64)h_cq->obj.hdl;<BR>+ cb_info.ioctl_rec.event_rec.handle.h_cq = 
(ib_cq_handle_t 
VOID_PTR64)HDL_TO_PTR(h_cq->obj.hdl);<BR> <BR>  /* The proxy 
handle must be valid now. */<BR>  if( !h_cq->obj.hdl_valid )<BR>@@ 
-3059,7 +3059,7 @@<BR>  {<BR>   /* Replace the pd 
handle with proxy's handle */<BR>   p_ioctl->out.attr.h_pd 
=<BR>-   (ib_pd_handle_t 
VOID_PTR64)p_ioctl->out.attr.h_pd->obj.hdl;<BR>+   (ib_pd_handle_t 
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_pd->obj.hdl);<BR>  }<BR>  else<BR>  {<BR>Index: 
core/al/kernel/al_ndi_cm.c<BR>===================================================================<BR>--- 
core/al/kernel/al_ndi_cm.c (revision 2386)<BR>+++ 
core/al/kernel/al_ndi_cm.c (revision 2388)<BR>@@ -891,7 +891,7 
@@<BR>  ib_qp_mod_t qp_mod;<BR>  ib_path_rec_t 
*p_path_rec;<BR>  ual_ndi_req_cm_ioctl_in_t *p_req = 
(ual_ndi_req_cm_ioctl_in_t* 
VOID_PTR64)p_query_rec->query_context;<BR>- ib_qp_handle_t VOID_PTR64 
h_qp = (ib_qp_handle_t VOID_PTR64)p_req->h_qp;<BR>+ ib_qp_handle_t 
VOID_PTR64 h_qp = (ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);<BR>  net32_t cid, 
old_cid;<BR> <BR>  AL_ENTER( AL_DBG_NDI );<BR>@@ -994,7 +994,7 
@@<BR>  ib_gid_pair_t user_query;<BR>  ib_query_req_t 
query_req;<BR>  ib_api_status_t status;<BR>- ib_qp_handle_t 
VOID_PTR64 h_qp = (ib_qp_handle_t 
VOID_PTR64)p_req->h_qp;<BR>+ ib_qp_handle_t VOID_PTR64 h_qp = 
(ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);<BR> <BR>  AL_ENTER( 
AL_DBG_NDI );<BR> <BR>@@ -1041,7 +1041,7 
@@<BR>  cl_ioctl_handle_t h_ioctl;<BR>  ib_service_record_t 
*service_record;<BR>  ual_ndi_req_cm_ioctl_in_t *p_req = 
(ual_ndi_req_cm_ioctl_in_t* 
VOID_PTR64)p_query_rec->query_context;<BR>- ib_qp_handle_t VOID_PTR64 
h_qp = (ib_qp_handle_t VOID_PTR64)p_req->h_qp;<BR>+ ib_qp_handle_t 
VOID_PTR64 h_qp = (ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);<BR> <BR>  AL_ENTER( 
AL_DBG_NDI );<BR> <BR>Index: 
core/al/kernel/al_proxy.c<BR>===================================================================<BR>--- 
core/al/kernel/al_proxy.c (revision 2386)<BR>+++ 
core/al/kernel/al_proxy.c (revision 2388)<BR>@@ -862,7 +862,7 
@@<BR>   break;<BR>  }<BR> <BR>- p_evt_rec->pnp.h_pnp 
= (ib_pnp_handle_t 
VOID_PTR64)p_pnp_rec->h_pnp->obj.hdl;<BR>+ p_evt_rec->pnp.h_pnp = 
(ib_pnp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_pnp_rec->h_pnp->obj.hdl);<BR>  p_pnp_rec->h_pnp->obj.hdl_valid 
= TRUE;<BR> <BR>  hdl =<BR>Index: 
core/al/al_verbs.h<BR>===================================================================<BR>--- 
core/al/al_verbs.h (revision 2386)<BR>+++ core/al/al_verbs.h (revision 
2388)<BR>@@ -402,7 +402,7 @@<BR> <BR> #define 
verbs_check_av(h_av) ((h_av)->h_ci_av || 
(h_av)->obj.hdl)<BR> #define convert_av_handle(h_qp, h_av) 
\<BR>- ((h_qp)->h_ci_qp?(h_av)->h_ci_av:(ib_av_handle_t 
VOID_PTR64)(h_av)->obj.hdl)<BR>+ ((h_qp)->h_ci_qp?(h_av)->h_ci_av:(ib_av_handle_t 
VOID_PTR64)HDL_TO_PTR((h_av)->obj.hdl))<BR> #define 
verbs_destroy_av(h_av) \<BR>  ual_destroy_av(h_av)<BR> <BR>Index: 
core/al/al_qp.c<BR>===================================================================<BR>--- 
core/al/al_qp.c (revision 2386)<BR>+++ core/al/al_qp.c (revision 
2388)<BR>@@ -62,6 +62,7 @@<BR> #include 
"al_verbs.h"<BR> <BR> #include "ib_common.h"<BR>+#include 
"basetsd.h"<BR> <BR> <BR> #define 
UNBOUND_PORT_GUID  0<BR>Index: 
core/al/user/ual_mcast.c<BR>===================================================================<BR>--- 
core/al/user/ual_mcast.c (revision 2386)<BR>+++ 
core/al/user/ual_mcast.c (revision 2388)<BR>@@ -98,7 +98,7 
@@<BR>   status = ioctl_buf.out.status;<BR>   if( 
status == IB_SUCCESS ){<BR>    h_mcast->obj.hdl = 
ioctl_buf.out.h_attach;<BR>-   h_mcast->h_ci_mcast = 
(ib_mcast_handle_t 
VOID_PTR64)ioctl_buf.out.h_attach;<BR>+   h_mcast->h_ci_mcast 
= (ib_mcast_handle_t VOID_PTR64) 
HDL_TO_PTR(ioctl_buf.out.h_attach);<BR>   }<BR>  }<BR> <BR>Index: 
core/al/user/ual_qp.c<BR>===================================================================<BR>--- 
core/al/user/ual_qp.c (revision 2386)<BR>+++ 
core/al/user/ual_qp.c (revision 2388)<BR>@@ -313,12 +313,12 
@@<BR>  qp_ioctl.in.h_pd = 
h_pd->obj.hdl;<BR>  qp_ioctl.in.qp_create = 
*p_qp_create;<BR>  qp_ioctl.in.qp_create.h_rq_cq 
=<BR>-  (ib_cq_handle_t 
VOID_PTR64)p_qp_create->h_rq_cq->obj.hdl;<BR>+  (ib_cq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_qp_create->h_rq_cq->obj.hdl);<BR>  qp_ioctl.in.qp_create.h_sq_cq 
=<BR>-  (ib_cq_handle_t 
VOID_PTR64)p_qp_create->h_sq_cq->obj.hdl;<BR>+  (ib_cq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_qp_create->h_sq_cq->obj.hdl);<BR>  if 
(p_qp_create->h_srq)<BR>   qp_ioctl.in.qp_create.h_srq 
=<BR>-   (ib_srq_handle_t 
VOID_PTR64)p_qp_create->h_srq->obj.hdl;<BR>+   (ib_srq_handle_t 
VOID_PTR64)HDL_TO_PTR(p_qp_create->h_srq->obj.hdl);<BR>  qp_ioctl.in.context 
= h_qp;<BR>  qp_ioctl.in.ev_notify = (h_qp->pfn_event_cb != NULL) ? 
TRUE : FALSE;<BR> <BR>Index: 
core/al/user/ual_mw.c<BR>===================================================================<BR>--- 
core/al/user/ual_mw.c (revision 2386)<BR>+++ 
core/al/user/ual_mw.c (revision 2388)<BR>@@ -278,7 +278,7 
@@<BR>  mw_ioctl.in.h_mw = 
h_mw->obj.hdl;<BR>  mw_ioctl.in.h_qp = 
h_qp->obj.hdl;<BR>  mw_ioctl.in.mw_bind = 
*p_mw_bind;<BR>- mw_ioctl.in.mw_bind.h_mr = (ib_mr_handle_t 
VOID_PTR64)p_mw_bind->h_mr->obj.hdl;<BR>+ mw_ioctl.in.mw_bind.h_mr = 
(ib_mr_handle_t VOID_PTR64) 
HDL_TO_PTR(p_mw_bind->h_mr->obj.hdl);<BR> <BR>  cl_status = 
do_al_dev_ioctl( UAL_BIND_MW,<BR>   &mw_ioctl.in, 
sizeof(mw_ioctl.in), &mw_ioctl.out, sizeof(mw_ioctl.out),<BR>Index: 
core/al/user/ual_cm_cep.c<BR>===================================================================<BR>--- 
core/al/user/ual_cm_cep.c (revision 2386)<BR>+++ 
core/al/user/ual_cm_cep.c (revision 2388)<BR>@@ -506,7 +506,7 
@@<BR>     cl_memclr(&ioctl, 
sizeof(ioctl));<BR>  ioctl.in.cid = 
cid;<BR>  ioctl.in.cm_req = *p_cm_req;<BR>- ioctl.in.cm_req.h_qp 
= (ib_qp_handle_t 
VOID_PTR64)p_cm_req->h_qp->obj.hdl;<BR>+ ioctl.in.cm_req.h_qp = 
(ib_qp_handle_t VOID_PTR64) 
HDL_TO_PTR(p_cm_req->h_qp->obj.hdl);<BR>  ioctl.in.paths[0] = 
*(p_cm_req->p_primary_path);<BR>  if( p_cm_req->p_alt_path 
)<BR>   ioctl.in.paths[1] = *(p_cm_req->p_alt_path);<BR>@@ 
-633,7 +633,7 @@<BR>  ioctl.in.context = 
context;<BR>  ioctl.in.cid = cid;<BR>  ioctl.in.cm_rep = 
*p_cm_rep;<BR>- ioctl.in.cm_rep.h_qp = (ib_qp_handle_t 
VOID_PTR64)p_cm_rep->h_qp->obj.hdl;<BR>+ ioctl.in.cm_rep.h_qp = 
(ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_cm_rep->h_qp->obj.hdl);<BR>  /* Copy 
private data, if any. */<BR>  if( p_cm_rep->p_rep_pdata 
)<BR>  {<BR>@@ -981,7 +981,7 @@<BR>     
cl_memclr(&ioctl,sizeof (ioctl));<BR>  ioctl.cid = 
cid;<BR>  ioctl.cm_lap = *p_cm_lap;<BR>- ioctl.cm_lap.h_qp = 
(ib_qp_handle_t 
VOID_PTR64)p_cm_lap->h_qp->obj.hdl;<BR>+ ioctl.cm_lap.h_qp = 
(ib_qp_handle_t VOID_PTR64) 
HDL_TO_PTR(p_cm_lap->h_qp->obj.hdl);<BR>  ioctl.alt_path = 
*(p_cm_lap->p_alt_path);<BR>  /* Copy private data, if any. 
*/<BR>  if( p_cm_lap->p_lap_pdata )<BR>@@ -1037,7 +1037,7 
@@<BR>     cl_memclr(&ioctl, sizeof 
(ioctl));<BR>  ioctl.in.cid = cid;<BR>  ioctl.in.cm_apr = 
*p_cm_apr;<BR>- ioctl.in.cm_apr.h_qp = (ib_qp_handle_t 
VOID_PTR64)p_cm_apr->h_qp->obj.hdl;<BR>+ ioctl.in.cm_apr.h_qp = 
(ib_qp_handle_t 
VOID_PTR64)HDL_TO_PTR(p_cm_apr->h_qp->obj.hdl);<BR>  if( 
p_cm_apr->p_info )<BR>  {<BR>   if( 
p_cm_apr->info_length > IB_APR_INFO_SIZE )<BR>Index: 
inc/iba/ib_types.h<BR>===================================================================<BR>--- 
inc/iba/ib_types.h (revision 2386)<BR>+++ inc/iba/ib_types.h (revision 
2388)<BR>@@ -56,15 +56,15 @@<BR> #define 
STRUCT_PTR64<BR> #endif<BR> <BR>+#define HDL_TO_PTR(hdl) 
Handle64ToHandle( (void * __ptr64) (hdl))<BR> <BR>-#pragma warning( disable 
: 4201)<BR>-#pragma warning( disable :4305)<BR>+#pragma warning( disable : 4201) 
//nameless union/structure<BR> <BR> <BR>-#define CONCAT(str1, str2) 
str1##str2<BR>+#define IB_CONCAT(str1, str2) 
str1##str2<BR> <BR> #define TO_LONG_PTR(type,member_name) 
\<BR>-    union { type member_name;  uint64_t 
CONCAT(member_name,_padding) ; }<BR>+    union { type 
member_name;  uint64_t IB_CONCAT(member_name,_padding) ; 
}<BR> <BR> <BR> <BR>@@ -8966,7 +8966,6 
@@<BR> */<BR> typedef struct _ib_event_rec<BR> {<BR>-#pragma 
warning( disable : 4201)<BR> <BR>  TO_LONG_PTR(void* 
, context) 
;<BR>  ib_async_event_t  type;<BR></FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Fab Tillier 
[mailto:ftillier@windows.microsoft.com] <BR><B>Sent:</B> Wednesday, April 30, 
2008 9:20 PM<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>
<DIV class=Section1>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;>Yikes!  You disable warning C4305 for everyone 
including ib_types.h?  Do you really think this is 
appropriate???<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;><o:p> </o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;>The more I look at the patch, the more I think it should 
be rolled back, sorry.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;><o:p> </o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;>-Fab<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: " color:#1F497D? 
Calibri?,?sans-serif?;><o:p> </o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " Tahoma?,?sans-serif??> 
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 
1: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<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>Hello,</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>I committed our WDK and __ptr64 patch into WinOF 
trunk, and WinOF and WinIB trunks were synchronized again.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>You can find below some further explanations 
:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>1. IBAL compiles now with WDK6001.18001. 
According to Microsoft, it should be the last and official 
release.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>We preserved the backward compatibility with 
DDK, but some intermediate versions of WDK may be 
incompatible</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>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</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>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)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>In addition, Microsoft fixed an internal 
compiler bug when compiling modules with long (__ptr64) pointers on functions 
(occurred only in x86 CHECKED environment).</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>So, you should not have problem with compilation 
after adjusting makefiles</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>3. This revision contains:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?> 3.1. All bugfixes from WinOF trunk, from 
rev. 939 to 1067</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?> 3.2. Mellanox __ptr64 solution and WDK 
poring, starting from rev. 2164</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?> 3.3. All bugfixes and patches from 
connectx branches (both Mellanox and WinOF)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>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).</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>We will appreciate your code review, just to be 
sure that we didn't forget to insert any minor patch or bug 
fix.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>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.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif?;color:blue?>Thanks,</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Naslednikov Alexander (a.k.a 
XaleX)</SPAN></B><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Windows 
Team</SPAN></B><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Mellanox 
Technologies </SPAN></B><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>_____________________________________________ 
</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>From: 
 </SPAN></B> <SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Alex Naslednikov  </SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Sent:  </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>Monday, April 21, 
2008 7:15 PM</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>To:    </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>Alex Naslednikov; 
'Smith, Stan'; Ishai Rabinovitz</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Cc:    </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>'ofw@lists.openfabrics.org'</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Subject:       </SPAN></B> 
<SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>RE: [ofw] 
WDK build environment migration thoughts</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Thanks,<BR></SPAN><BR><B>Naslednikov Alexander (a.k.a 
XaleX)<BR>Windows Team<BR>Mellanox Technologies</B><o:p></o:p></P>
<P class=MsoNormal><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>_____________________________________________ 
</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>From: 
 </SPAN></B> <SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Alex Naslednikov  </SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Sent:  </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>Thursday, April 
10, 2008 4:09 PM</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>To:    </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>'Smith, Stan'; 
Ishai Rabinovitz</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Cc:    </SPAN></B> <SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>ofw@lists.openfabrics.org</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " 
Tahoma?,?sans-serif??>Subject:       </SPAN></B> 
<SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: " Tahoma?,?sans-serif??>RE: [ofw] 
WDK build environment migration thoughts</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Hi 
all,</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>It's a good 
idea to clarify some points before announcing Mellanox patch for WDK porting and 
__ptr64 problems.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Hope, these 
explanations will be informative enough and not so long.</SPAN><o:p></o:p></P>
<P><B><U><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>1. 
__ptr64 problem</SPAN></U></B><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Briefly 
speaking, this problem arises when copying 32bit len pointer into 64bit len 
pointer. In this case,</SPAN><U> </U><U><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>signed pointer 
extension</SPAN></U> <SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>will take place.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>When user 
code do operation like </SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>s_ptr = 
&my_struct;</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>my_type* 
__ptr64 ptr = s_ptr;</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Than kernel 
will receive ptr with invalid upper bits data (4 bytes 
FF).</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>To avoid 
signed pointer extension, PtrToPtr64() function should be 
used.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Also, I 
found some other places where dangerous signed pointer extension took place, 
even on 32bit kernel.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Yet another 
problem that arises with __ptr64 attribute is internal compiler error 
(C1001)  in WDK when using __ptr64 pointer to function 
(callback)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>This 
problem was described in ofw discussion, you can see also 
:</SPAN><o:p></o:p></P>
<P><A href="http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx</SPAN></A><o:p></o:p></P>
<P><A 
href="http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html</SPAN></A><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??> (posted by Jan from 
OFW)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Our 
solution:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>(like 
my_type* __ptr64 ptr = PtrToPtr64(s_ptr);  )</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>2. So, we 
decided about another solution:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??> All 
__ptr64 occurrences were replaced by either:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??> i) 
TO_LONG_PTR(type, field) macro, when occurred inside 
structure</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>ii) 
VOID_PTR64 macro otherwise (defined as void macro)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>#define 
CONCAT(str1, str2) str1##str2</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>#define 
TO_LONG_PTR(type,member_name) \</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>    union { type member_name;  uint64_t 
CONCAT(member_name,_padding) ; }</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Thus, we 
can both preserve on a uniform shapes of structs in user and kernel and to avoid 
unsafe pointer arithmetic !</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>The patch 
now is much more readable, but it sill consist of thousands 
lines.</SPAN><o:p></o:p></P>
<P><B><U><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>2. 
Migration to WDK</SPAN></U></B><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Main issue 
here was to preserve on backward compatibility with DDK</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>We were 
able to compile our stack with WDK, while the main problems we found were 
:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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 </SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>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)</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>2.verify.src script in WDK (new add-on) checks if your 
SOURCES file is in appropriate format.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>For 
example, you can't set implicitly path to system .dll in TARGETLIBS, but to use 
USE_<MODULE_NAME> =1 macro</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Example:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Old code : 
</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??> ....</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>TARGETLIBS= 
\</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>   
$(CRT_LIB_PATH)\msvcprt.lib\</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>   
$(SDK_LIB_PATH)\Ws2_32.lib\</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>   $(TARGETPATH)\*\mtcr.lib</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??> </SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>New code 
:</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>USE_MSVCRT=1</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>USE_NTDLL=1</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??> </SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>TARGETLIBS= 
\</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>   
$(SDK_LIB_PATH)\Ws2_32.lib\</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>   $(TARGETPATH)\*\mtcr.lib</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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)</SPAN><o:p></o:p></P>
<P class=MsoNormal><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Currently, 
we continue testing and will advertise these patches right after the testing 
will finish</SPAN><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Naslednikov Alexander (a.k.a 
XaleX)</SPAN></B><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Windows 
Team</SPAN></B><o:p></o:p></P>
<P><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Mellanox 
Technologies</SPAN></B> <o:p></o:p></P>
<P class=MsoNormal><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>-----Original Message-----</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>From: 
ofw-bounces@lists.openfabrics.org [</SPAN><A 
href="mailto:ofw-bounces@lists.openfabrics.org"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>mailto:ofw-bounces@lists.openfabrics.org</SPAN></A><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>] On Behalf Of 
Smith, Stan</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Sent: 
Tuesday, April 08, 2008 4:10 PM</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>To: Ishai 
Rabinovitz</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Cc: 
ofw@lists.openfabrics.org</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Subject: 
[ofw] WDK build environment migration thoughts</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Hello,</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>  I 
strongly believe it would help the WinOF community in transitioning to the WDK 
build environment if the connectX branch</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>(svn:gen1\branches\ConnectX) was used as a WDK build 
environment staging grounds prior to merging the WDK modifications into the 
mainline trunk.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>This has 
been talked about before although it still (as of last Friday) does not build 
using the latest WDK version.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??> </SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>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</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>  1) 
how to build in the WDK environment,</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>     which version of the WDK is 
required + a URL link where to get the WDK.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>  2) 
An explanation of why and how the __ptr64 attributes were removed along with 
how</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>     others should correct their codes 
containing __ptr64 attributes.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>  3) 
updates to the WinOF wiki page describing how to build in the WDK 
env.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Let this 
branch exist for one week, receiving feedback from the list and then merge into 
the mainline trunk.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Using this 
approach is certainly community friendly and may prevent developer 
surprises.</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>ConnectX 
branch availability dates plus when the actual WDK fixes would be merged into 
the mainline trunk would be published beforehand.</SPAN><o:p></o:p></P>
<P class=MsoNormal><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>Thanks for 
your consideration,</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>Stan.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><o:p> </o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>_______________________________________________</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " Arial?,?sans-serif??>ofw mailing 
list</SPAN><o:p></o:p></P>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>ofw@lists.openfabrics.org</SPAN><o:p></o:p></P>
<P><A href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: " 
Arial?,?sans-serif??>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</SPAN></A><o:p></o:p></P></DIV></BODY></HTML>