What exactly are FUNC_PTR64 and VOID_PTR64? Given:
typedef struct _ib_qp* VOID_PTR64 ib_qp_handle_t; ib_qp_handle_t qp; What does sizeof(qp) return? As for the steps, I'm missing something. Step 1 looks like it breaks compatibility. Step 3 looks like it undoes what step 1 did, so I'm not sure why step 1 was done. Were these just intermediate steps that you used to create the actual patch? _____ From: Alex Naslednikov [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 12:31 PM To: Hefty, Sean; Smith, Stan; Ishai Rabinovitz Cc: [email protected] Subject: RE: [ofw] WDK build environment migration thoughts Question: It's still not clear to me how you maintain binary compatibility with the IBAL APIs. The IBAL calls take 64-bit pointers as input parameters. What are the definitions for the ib_blah_handle_t types? We did the following (major steps): 1. Replace all ib_<type>_handle_t types by its direct invocation, say struct _ib_<type>_ * 2. Next, replace all __ptr64 either by TO_LONG_PTR macro (if used inside struct definition), or one of void macros (FUNC_PTR64, VOID_PTR64 etc) otherwise Typedefs now looks like : typedef struct _ib_qp* VOID_PTR64 ib_qp_handle_t; 3. Next, replace back all appearances of (struct ib_<type>_*) by ib_<type>_handle_t inside function declarations (because of "const" modifier problems) 4. Several other minor steps XaleX _____ From: Sean Hefty [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 9:01 PM To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz Cc: [email protected] Subject: RE: [ofw] WDK build environment migration thoughts Q2.Does TO_LONG_PTR work for both big endian and little endian systems? TO_LONG_PTR works only with little endian, because we do not support PPC platform Currently, there's no need to extend it to support big endian OFA does support PPC platforms, plus Itanium can be configured for either little or big endian format. I'm fine deferring adding this support, but the code should not assume that it will always be little endian. Q3. How is the padded space initialized? Inside sdp, all padded space was initialized by class constructor (except one specific case) In all other code, that not C++, padded space was initialized by cl_memclr before setting the field and before calling to ioctl procedure Please, see my next mail with examples from the code It's kind of ugly to require setting padded fields to specific values. This only needs to be done when crossing from a 32-bit to 64-bit boundary, so we can restrict this to the kernel proxy. (Btw, you can replace the unnamed union and add padding to structures only if compiling in 32-bit mode.) It's still not clear to me how you maintain binary compatibility with the IBAL APIs. The IBAL calls take 64-bit pointers as input parameters. What are the definitions for the ib_blah_handle_t types? - Sean
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
