[ofw] Patch for C4305 warning treatment
Alex Naslednikov
alexn at mellanox.co.il
Tue May 6 01:00:29 PDT 2008
Sean,
You proposed here another solution for __ptr64 problem, and we discussed
its profs and cons before (please, see my first post on this topic)
But this proposal is not relevant to my patch at all.
The patch solves compiler warning C4305, when truncating some uint64_t
into (void *), that is only 4 bytes on x86 machines. That is, truncation
is from 64 to 32 bit, and not vice versa operation.
Why such things may happen and why there's no lost of information in our
case ?
IBAL often uses "handles" (example : h_qp->obj.hdl) to pass array index
of some physical memory address. Array can't contain more than 4Gb
entries, therefore hdl can be defined as uint32_t
The problem is that such "handles" were defined as uint64_t, so compiler
warn us about truncation from this "handle" to pointer on x86 platform.
To avoid this warning , appropriate castings are required, and this
patch solves it.
This warning had been never occured before, because originally all types
like <type>_handle_t were defined as __ptr64 pointer.
Now, __ptr64 was removed from there, and these *_handle_t types defined
as usual pointers. So, this problem should arise in your solution, as
well
XaleX
________________________________
From: Sean Hefty [mailto:sean.hefty at intel.com]
Sent: Monday, May 05, 2008 5:47 PM
To: Alex Naslednikov; Fab Tillier; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] Patch for C4305 warning treatment
The only place we have to worry about converting from 32 bit to 64 bit
is IOCTLs. Just have IOCTL structures use UINT64 fields, aligned on a
64-bit boundary in the structure. (You can't passing pointers to the
kernel that you can directly dereference anyway.) Remove __ptr64
everywhere else.
- Sean
[PTR64] Explicitly casting from uint64_t to pointer in order to avoid
warning C4305.
Macro CONCAT renamed to IB_CONCAT
Signed-off by: XaleX
Index: ulp/opensm/user/include/iba/ib_types.h
===================================================================
--- ulp/opensm/user/include/iba/ib_types.h (revision 2386)
+++ ulp/opensm/user/include/iba/ib_types.h (revision 2388)
@@ -81,10 +81,10 @@
#define STRUCT_PTR64
#endif
-#define CONCAT(str1, str2) str1##str2
+#define IB_CONCAT(str1, str2) str1##str2
#define TO_LONG_PTR(type,member_name) \
- union { type member_name; uint64_t CONCAT(member_name,_padding) ;
}
+ union { type member_name; uint64_t IB_CONCAT(member_name,_padding)
; }
Index: ulp/opensm/user/include/iba/ib_types_extended.h
===================================================================
--- ulp/opensm/user/include/iba/ib_types_extended.h (revision 2386)
+++ ulp/opensm/user/include/iba/ib_types_extended.h (revision 2388)
@@ -57,32 +57,6 @@
#define __ptr64
#endif
-#ifndef FUNC_PTR64
-#define FUNC_PTR64
-#endif
-
-#ifndef TYPEDEF_PTR64
-#define TYPEDEF_PTR64
-#endif
-
-#ifndef VOID_PTR64
-#define VOID_PTR64
-#endif
-
-#ifndef STRUCT_PTR64
-#define STRUCT_PTR64
-#endif
-
-
-//#ifndef CONCAT
-#define CONCAT(str1, str2) str1##str2
-//#endif
-
-//#ifndef T0_LONG_PTR
-#define TO_LONG_PTR(type,member_name) \
- union { type member_name; uint64_t CONCAT(member_name,_padding) ;
}
-//#endif
-
/*
* Defines the size of user available data in communication management
MADs
*/
Index: ulp/sdp/include/SdpShared.h
===================================================================
--- ulp/sdp/include/SdpShared.h (revision 2386)
+++ ulp/sdp/include/SdpShared.h (revision 2388)
@@ -67,13 +67,13 @@
#define IOCTL_WSP_CLOSE_SOCKET CTL_CODE(FILE_DEVICE_UNKNOWN, 0x811,
METHOD_BUFFERED ,FILE_ANY_ACCESS)
#define IOCTL_WSP_USER_THREAD CTL_CODE(FILE_DEVICE_UNKNOWN, 0x812,
METHOD_BUFFERED ,FILE_ANY_ACCESS)
-#ifndef CONCAT
-#define CONCAT(str1, str2) str1##str2
+#ifndef IB_CONCAT
+#define IB_CONCAT(str1, str2) str1##str2
#endif
#ifndef TO_LONG_PTR
#define TO_LONG_PTR(type,member_name) \
- union { type member_name; uint64_t CONCAT(member_name,_padding) ;
} ;
+ union { type member_name; uint64_t IB_CONCAT(member_name,_padding)
; } ;
#endif
// Data structures that are used for connect
Index: ulp/wsd/user/ibsp_iblow.c
===================================================================
--- ulp/wsd/user/ibsp_iblow.c (revision 2386)
+++ ulp/wsd/user/ibsp_iblow.c (revision 2388)
@@ -66,8 +66,8 @@
IBSP_ENTER( IBSP_DBG_IO );
- wr = (struct _wr * VOID_PTR64)wc->wr_id;
- p_recv_wr = (struct _recv_wr * VOID_PTR64)wc->wr_id;
+ wr = (struct _wr * VOID_PTR64)HDL_TO_PTR(wc->wr_id);
+ p_recv_wr = (struct _recv_wr * VOID_PTR64)HDL_TO_PTR(wc->wr_id);
CL_ASSERT( wr );
Index: core/al/kernel/al_proxy_verbs.c
===================================================================
--- core/al/kernel/al_proxy_verbs.c (revision 2386)
+++ core/al/kernel/al_proxy_verbs.c (revision 2388)
@@ -352,7 +352,7 @@
cb_info.rec_type = CA_ERROR_REC;
/* Return the Proxy's open_ca handle and the user's context */
cb_info.ioctl_rec.event_rec = *p_err_rec;
- cb_info.ioctl_rec.event_rec.handle.h_ca = (ib_ca_handle_t
VOID_PTR64)h_ca->obj.hdl;
+ cb_info.ioctl_rec.event_rec.handle.h_ca = (ib_ca_handle_t
VOID_PTR64)HDL_TO_PTR(h_ca->obj.hdl);
/* The proxy handle must be valid now. */
if( !h_ca->obj.hdl_valid )
@@ -987,7 +987,7 @@
cb_info.rec_type = SRQ_ERROR_REC;
/* Return the Proxy's SRQ handle and the user's context */
cb_info.ioctl_rec.event_rec = *p_err_rec;
- cb_info.ioctl_rec.event_rec.handle.h_srq = (ib_srq_handle_t
VOID_PTR64)h_srq->obj.hdl;
+ cb_info.ioctl_rec.event_rec.handle.h_srq = (ib_srq_handle_t
VOID_PTR64) HDL_TO_PTR(h_srq->obj.hdl);
/* The proxy handle must be valid now. */
if( !h_srq->obj.hdl_valid )
@@ -1291,7 +1291,7 @@
cb_info.rec_type = QP_ERROR_REC;
/* Return the Proxy's QP handle and the user's context */
cb_info.ioctl_rec.event_rec = *p_err_rec;
- cb_info.ioctl_rec.event_rec.handle.h_qp = (ib_qp_handle_t
VOID_PTR64)h_qp->obj.hdl;
+ cb_info.ioctl_rec.event_rec.handle.h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(h_qp->obj.hdl);
/* The proxy handle must be valid now. */
if( !h_qp->obj.hdl_valid )
@@ -1491,7 +1491,7 @@
if( p_ioctl->out.attr.h_pd )
{
p_ioctl->out.attr.h_pd =
- (ib_pd_handle_t VOID_PTR64)p_ioctl->out.attr.h_pd->obj.hdl;
+ (ib_pd_handle_t
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_pd->obj.hdl);
}
else
{
@@ -1500,7 +1500,7 @@
if( p_ioctl->out.attr.h_sq_cq )
{
p_ioctl->out.attr.h_sq_cq =
- (ib_cq_handle_t VOID_PTR64)p_ioctl->out.attr.h_sq_cq->obj.hdl;
+ (ib_cq_handle_t
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_sq_cq->obj.hdl);
}
else
{
@@ -1509,7 +1509,7 @@
if( p_ioctl->out.attr.h_rq_cq )
{
p_ioctl->out.attr.h_rq_cq =
- (ib_cq_handle_t VOID_PTR64)p_ioctl->out.attr.h_rq_cq->obj.hdl;
+ (ib_cq_handle_t
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_rq_cq->obj.hdl);
}
else
{
@@ -1518,7 +1518,7 @@
if( p_ioctl->out.attr.h_srq )
{
p_ioctl->out.attr.h_srq =
- (ib_srq_handle_t VOID_PTR64)p_ioctl->out.attr.h_srq->obj.hdl;
+ (ib_srq_handle_t
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_srq->obj.hdl);
}
else
{
@@ -2063,7 +2063,7 @@
cb_info.rec_type = CQ_ERROR_REC;
/* Return the Proxy's cq handle and the user's context */
cb_info.ioctl_rec.event_rec = *p_err_rec;
- cb_info.ioctl_rec.event_rec.handle.h_cq = (ib_cq_handle_t
VOID_PTR64)h_cq->obj.hdl;
+ cb_info.ioctl_rec.event_rec.handle.h_cq = (ib_cq_handle_t
VOID_PTR64)HDL_TO_PTR(h_cq->obj.hdl);
/* The proxy handle must be valid now. */
if( !h_cq->obj.hdl_valid )
@@ -3059,7 +3059,7 @@
{
/* Replace the pd handle with proxy's handle */
p_ioctl->out.attr.h_pd =
- (ib_pd_handle_t VOID_PTR64)p_ioctl->out.attr.h_pd->obj.hdl;
+ (ib_pd_handle_t
VOID_PTR64)HDL_TO_PTR(p_ioctl->out.attr.h_pd->obj.hdl);
}
else
{
Index: core/al/kernel/al_ndi_cm.c
===================================================================
--- core/al/kernel/al_ndi_cm.c (revision 2386)
+++ core/al/kernel/al_ndi_cm.c (revision 2388)
@@ -891,7 +891,7 @@
ib_qp_mod_t qp_mod;
ib_path_rec_t *p_path_rec;
ual_ndi_req_cm_ioctl_in_t *p_req = (ual_ndi_req_cm_ioctl_in_t*
VOID_PTR64)p_query_rec->query_context;
- ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)p_req->h_qp;
+ ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);
net32_t cid, old_cid;
AL_ENTER( AL_DBG_NDI );
@@ -994,7 +994,7 @@
ib_gid_pair_t user_query;
ib_query_req_t query_req;
ib_api_status_t status;
- ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)p_req->h_qp;
+ ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);
AL_ENTER( AL_DBG_NDI );
@@ -1041,7 +1041,7 @@
cl_ioctl_handle_t h_ioctl;
ib_service_record_t *service_record;
ual_ndi_req_cm_ioctl_in_t *p_req = (ual_ndi_req_cm_ioctl_in_t*
VOID_PTR64)p_query_rec->query_context;
- ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)p_req->h_qp;
+ ib_qp_handle_t VOID_PTR64 h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(p_req->h_qp);
AL_ENTER( AL_DBG_NDI );
Index: core/al/kernel/al_proxy.c
===================================================================
--- core/al/kernel/al_proxy.c (revision 2386)
+++ core/al/kernel/al_proxy.c (revision 2388)
@@ -862,7 +862,7 @@
break;
}
- p_evt_rec->pnp.h_pnp = (ib_pnp_handle_t
VOID_PTR64)p_pnp_rec->h_pnp->obj.hdl;
+ p_evt_rec->pnp.h_pnp = (ib_pnp_handle_t
VOID_PTR64)HDL_TO_PTR(p_pnp_rec->h_pnp->obj.hdl);
p_pnp_rec->h_pnp->obj.hdl_valid = TRUE;
hdl =
Index: core/al/al_verbs.h
===================================================================
--- core/al/al_verbs.h (revision 2386)
+++ core/al/al_verbs.h (revision 2388)
@@ -402,7 +402,7 @@
#define verbs_check_av(h_av) ((h_av)->h_ci_av || (h_av)->obj.hdl)
#define convert_av_handle(h_qp, h_av) \
- ((h_qp)->h_ci_qp?(h_av)->h_ci_av:(ib_av_handle_t
VOID_PTR64)(h_av)->obj.hdl)
+ ((h_qp)->h_ci_qp?(h_av)->h_ci_av:(ib_av_handle_t
VOID_PTR64)HDL_TO_PTR((h_av)->obj.hdl))
#define verbs_destroy_av(h_av) \
ual_destroy_av(h_av)
Index: core/al/al_qp.c
===================================================================
--- core/al/al_qp.c (revision 2386)
+++ core/al/al_qp.c (revision 2388)
@@ -62,6 +62,7 @@
#include "al_verbs.h"
#include "ib_common.h"
+#include "basetsd.h"
#define UNBOUND_PORT_GUID 0
Index: core/al/user/ual_mcast.c
===================================================================
--- core/al/user/ual_mcast.c (revision 2386)
+++ core/al/user/ual_mcast.c (revision 2388)
@@ -98,7 +98,7 @@
status = ioctl_buf.out.status;
if( status == IB_SUCCESS ){
h_mcast->obj.hdl = ioctl_buf.out.h_attach;
- h_mcast->h_ci_mcast = (ib_mcast_handle_t
VOID_PTR64)ioctl_buf.out.h_attach;
+ h_mcast->h_ci_mcast = (ib_mcast_handle_t VOID_PTR64)
HDL_TO_PTR(ioctl_buf.out.h_attach);
}
}
Index: core/al/user/ual_qp.c
===================================================================
--- core/al/user/ual_qp.c (revision 2386)
+++ core/al/user/ual_qp.c (revision 2388)
@@ -313,12 +313,12 @@
qp_ioctl.in.h_pd = h_pd->obj.hdl;
qp_ioctl.in.qp_create = *p_qp_create;
qp_ioctl.in.qp_create.h_rq_cq =
- (ib_cq_handle_t VOID_PTR64)p_qp_create->h_rq_cq->obj.hdl;
+ (ib_cq_handle_t VOID_PTR64)HDL_TO_PTR(p_qp_create->h_rq_cq->obj.hdl);
qp_ioctl.in.qp_create.h_sq_cq =
- (ib_cq_handle_t VOID_PTR64)p_qp_create->h_sq_cq->obj.hdl;
+ (ib_cq_handle_t VOID_PTR64)HDL_TO_PTR(p_qp_create->h_sq_cq->obj.hdl);
if (p_qp_create->h_srq)
qp_ioctl.in.qp_create.h_srq =
- (ib_srq_handle_t VOID_PTR64)p_qp_create->h_srq->obj.hdl;
+ (ib_srq_handle_t VOID_PTR64)HDL_TO_PTR(p_qp_create->h_srq->obj.hdl);
qp_ioctl.in.context = h_qp;
qp_ioctl.in.ev_notify = (h_qp->pfn_event_cb != NULL) ? TRUE : FALSE;
Index: core/al/user/ual_mw.c
===================================================================
--- core/al/user/ual_mw.c (revision 2386)
+++ core/al/user/ual_mw.c (revision 2388)
@@ -278,7 +278,7 @@
mw_ioctl.in.h_mw = h_mw->obj.hdl;
mw_ioctl.in.h_qp = h_qp->obj.hdl;
mw_ioctl.in.mw_bind = *p_mw_bind;
- mw_ioctl.in.mw_bind.h_mr = (ib_mr_handle_t
VOID_PTR64)p_mw_bind->h_mr->obj.hdl;
+ mw_ioctl.in.mw_bind.h_mr = (ib_mr_handle_t VOID_PTR64)
HDL_TO_PTR(p_mw_bind->h_mr->obj.hdl);
cl_status = do_al_dev_ioctl( UAL_BIND_MW,
&mw_ioctl.in, sizeof(mw_ioctl.in), &mw_ioctl.out,
sizeof(mw_ioctl.out),
Index: core/al/user/ual_cm_cep.c
===================================================================
--- core/al/user/ual_cm_cep.c (revision 2386)
+++ core/al/user/ual_cm_cep.c (revision 2388)
@@ -506,7 +506,7 @@
cl_memclr(&ioctl, sizeof(ioctl));
ioctl.in.cid = cid;
ioctl.in.cm_req = *p_cm_req;
- ioctl.in.cm_req.h_qp = (ib_qp_handle_t
VOID_PTR64)p_cm_req->h_qp->obj.hdl;
+ ioctl.in.cm_req.h_qp = (ib_qp_handle_t VOID_PTR64)
HDL_TO_PTR(p_cm_req->h_qp->obj.hdl);
ioctl.in.paths[0] = *(p_cm_req->p_primary_path);
if( p_cm_req->p_alt_path )
ioctl.in.paths[1] = *(p_cm_req->p_alt_path);
@@ -633,7 +633,7 @@
ioctl.in.context = context;
ioctl.in.cid = cid;
ioctl.in.cm_rep = *p_cm_rep;
- ioctl.in.cm_rep.h_qp = (ib_qp_handle_t
VOID_PTR64)p_cm_rep->h_qp->obj.hdl;
+ ioctl.in.cm_rep.h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(p_cm_rep->h_qp->obj.hdl);
/* Copy private data, if any. */
if( p_cm_rep->p_rep_pdata )
{
@@ -981,7 +981,7 @@
cl_memclr(&ioctl,sizeof (ioctl));
ioctl.cid = cid;
ioctl.cm_lap = *p_cm_lap;
- ioctl.cm_lap.h_qp = (ib_qp_handle_t
VOID_PTR64)p_cm_lap->h_qp->obj.hdl;
+ ioctl.cm_lap.h_qp = (ib_qp_handle_t VOID_PTR64)
HDL_TO_PTR(p_cm_lap->h_qp->obj.hdl);
ioctl.alt_path = *(p_cm_lap->p_alt_path);
/* Copy private data, if any. */
if( p_cm_lap->p_lap_pdata )
@@ -1037,7 +1037,7 @@
cl_memclr(&ioctl, sizeof (ioctl));
ioctl.in.cid = cid;
ioctl.in.cm_apr = *p_cm_apr;
- ioctl.in.cm_apr.h_qp = (ib_qp_handle_t
VOID_PTR64)p_cm_apr->h_qp->obj.hdl;
+ ioctl.in.cm_apr.h_qp = (ib_qp_handle_t
VOID_PTR64)HDL_TO_PTR(p_cm_apr->h_qp->obj.hdl);
if( p_cm_apr->p_info )
{
if( p_cm_apr->info_length > IB_APR_INFO_SIZE )
Index: inc/iba/ib_types.h
===================================================================
--- inc/iba/ib_types.h (revision 2386)
+++ inc/iba/ib_types.h (revision 2388)
@@ -56,15 +56,15 @@
#define STRUCT_PTR64
#endif
+#define HDL_TO_PTR(hdl) Handle64ToHandle( (void * __ptr64) (hdl))
-#pragma warning( disable : 4201)
-#pragma warning( disable :4305)
+#pragma warning( disable : 4201) //nameless union/structure
-#define CONCAT(str1, str2) str1##str2
+#define IB_CONCAT(str1, str2) str1##str2
#define TO_LONG_PTR(type,member_name) \
- union { type member_name; uint64_t CONCAT(member_name,_padding) ;
}
+ union { type member_name; uint64_t IB_CONCAT(member_name,_padding)
; }
@@ -8966,7 +8966,6 @@
*/
typedef struct _ib_event_rec
{
-#pragma warning( disable : 4201)
TO_LONG_PTR(void* , context) ;
ib_async_event_t type;
________________________________
From: Fab Tillier [mailto:ftillier at windows.microsoft.com]
Sent: Wednesday, April 30, 2008 9:20 PM
To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration thoughts
Yikes! You disable warning C4305 for everyone including ib_types.h? Do
you really think this is appropriate???
The more I look at the patch, the more I think it should be rolled back,
sorry.
-Fab
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Alex Naslednikov
Sent: Wednesday, April 30, 2008 1:20 AM
To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration thoughts
Hello,
I committed our WDK and __ptr64 patch into WinOF trunk, and WinOF and
WinIB trunks were synchronized again.
You can find below some further explanations :
1. IBAL compiles now with WDK6001.18001. According to Microsoft, it
should be the last and official release.
We preserved the backward compatibility with DDK, but some intermediate
versions of WDK may be incompatible
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
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)
In addition, Microsoft fixed an internal compiler bug when compiling
modules with long (__ptr64) pointers on functions (occurred only in x86
CHECKED environment).
So, you should not have problem with compilation after adjusting
makefiles
3. This revision contains:
3.1. All bugfixes from WinOF trunk, from rev. 939 to 1067
3.2. Mellanox __ptr64 solution and WDK poring, starting from rev. 2164
3.3. All bugfixes and patches from connectx branches (both Mellanox and
WinOF)
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).
We will appreciate your code review, just to be sure that we didn't
forget to insert any minor patch or bug fix.
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.
Thanks,
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
_____________________________________________
From: Alex Naslednikov
Sent: Monday, April 21, 2008 7:15 PM
To: Alex Naslednikov; 'Smith, Stan'; Ishai Rabinovitz
Cc: 'ofw at lists.openfabrics.org'
Subject: RE: [ofw] WDK build environment migration thoughts
Hi all,
I would like to repost my previous message, because I haven't received
yet your comments.
Our regression seems to be stable, so we are going to commit the change
into WinOF trunk the nearest time.
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.
Be aware that all the modules not contained in Mellanox WinIB stack
(like udapl, vnic) should be also changed according to this methodology.
It is very large change, so I'll appreciate your time and effort while
reviewing the methodology and the patch itself.
Thanks,
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
_____________________________________________
From: Alex Naslednikov
Sent: Thursday, April 10, 2008 4:09 PM
To: 'Smith, Stan'; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration thoughts
Hi all,
It's a good idea to clarify some points before announcing Mellanox patch
for WDK porting and __ptr64 problems.
Hope, these explanations will be informative enough and not so long.
1. __ptr64 problem
Briefly speaking, this problem arises when copying 32bit len pointer
into 64bit len pointer. In this case, signed pointer extension will take
place.
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.
When user code do operation like
s_ptr = &my_struct;
my_type* __ptr64 ptr = s_ptr;
Than kernel will receive ptr with invalid upper bits data (4 bytes FF).
To avoid signed pointer extension, PtrToPtr64() function should be used.
Also, I found some other places where dangerous signed pointer extension
took place, even on 32bit kernel.
Yet another problem that arises with __ptr64 attribute is internal
compiler error (C1001) in WDK when using __ptr64 pointer to function
(callback)
This problem was described in ofw discussion, you can see also :
http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx
<http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx>
http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html
<http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html>
(posted by Jan from OFW)
Our solution:
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.
(like my_type* __ptr64 ptr = PtrToPtr64(s_ptr); )
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
2. So, we decided about another solution:
All __ptr64 occurrences were replaced by either:
i) TO_LONG_PTR(type, field) macro, when occurred inside structure
ii) VOID_PTR64 macro otherwise (defined as void macro)
#define CONCAT(str1, str2) str1##str2
#define TO_LONG_PTR(type,member_name) \
union { type member_name; uint64_t CONCAT(member_name,_padding) ; }
Thus, we can both preserve on a uniform shapes of structs in user and
kernel and to avoid unsafe pointer arithmetic !
The patch now is much more readable, but it sill consist of thousands
lines.
2. Migration to WDK
Main issue here was to preserve on backward compatibility with DDK
We were able to compile our stack with WDK, while the main problems we
found were :
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
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)
2.verify.src script in WDK (new add-on) checks if your SOURCES file is
in appropriate format.
For example, you can't set implicitly path to system .dll in TARGETLIBS,
but to use USE_<MODULE_NAME> =1 macro
Example:
Old code :
....
TARGETLIBS= \
$(CRT_LIB_PATH)\msvcprt.lib\
$(SDK_LIB_PATH)\Ws2_32.lib\
$(TARGETPATH)\*\mtcr.lib
New code :
USE_MSVCRT=1
USE_NTDLL=1
TARGETLIBS= \
$(SDK_LIB_PATH)\Ws2_32.lib\
$(TARGETPATH)\*\mtcr.lib
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)
Currently, we continue testing and will advertise these patches right
after the testing will finish
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
-----Original Message-----
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org
<mailto:ofw-bounces at lists.openfabrics.org> ] On Behalf Of Smith, Stan
Sent: Tuesday, April 08, 2008 4:10 PM
To: Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: [ofw] WDK build environment migration thoughts
Hello,
I strongly believe it would help the WinOF community in transitioning
to the WDK build environment if the connectX branch
(svn:gen1\branches\ConnectX) was used as a WDK build environment staging
grounds prior to merging the WDK modifications into the mainline trunk.
This has been talked about before although it still (as of last Friday)
does not build using the latest WDK version.
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
1) how to build in the WDK environment,
which version of the WDK is required + a URL link where to get the
WDK.
2) An explanation of why and how the __ptr64 attributes were removed
along with how
others should correct their codes containing __ptr64 attributes.
3) updates to the WinOF wiki page describing how to build in the WDK
env.
Let this branch exist for one week, receiving feedback from the list and
then merge into the mainline trunk.
Using this approach is certainly community friendly and may prevent
developer surprises.
ConnectX branch availability dates plus when the actual WDK fixes would
be merged into the mainline trunk would be published beforehand.
Thanks for your consideration,
Stan.
_______________________________________________
ofw mailing list
ofw at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
<http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080506/b0535fbc/attachment.html>
More information about the ofw
mailing list