[ofw] WDK build environment migration thoughts

Alex Naslednikov alexn at mellanox.co.il
Mon Apr 21 12:31:06 PDT 2008


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:sean.hefty at intel.com] 
Sent: Monday, April 21, 2008 9:01 PM
To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080421/b0ecd5e0/attachment.html>


More information about the ofw mailing list