[ofw] WDK build environment migration thoughts

[Sean Hefty]

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:alexn at mellanox.co.il] 
Sent: Monday, April 21, 2008 12:31 PM
To: Hefty, Sean; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
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: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/af343d64/attachment.html>