<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:w =
"urn:schemas-microsoft-com:office:word" xmlns:o =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE>RE: [ofw] WDK build environment migration thoughts</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: blue; TEXT-DECORATION: underline
}
P {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
page: Section1
}
</STYLE>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><SPAN
class=228312419-21042008>Question: </SPAN>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?</SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"></SPAN></FONT> </DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>We did the following (major
steps):</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>1. Replace all ib_<type>_handle_t types by its
direct invocation, say struct _ib_<type>_ *</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>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</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>Typedefs now looks like : typedef struct _ib_qp*
VOID_PTR64 ib_qp_handle_t;</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>3. Next, replace back all appearances of (struct
ib_<type>_*) by ib_<type>_handle_t inside function declarations
(because of "const" modifier problems)</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>4. Several other minor steps</SPAN></o:p></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008></SPAN></o:p></SPAN> </DIV>
<DIV><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p><SPAN
class=228312419-21042008>XaleX</SPAN></o:p></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Sean Hefty [mailto:sean.hefty@intel.com]
<BR><B>Sent:</B> Monday, April 21, 2008 9:01 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>
<DIV
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<P class=MsoNormal><FONT face=Arial color=black size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Q2.</SPAN></FONT><FONT
face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Does TO_LONG_PTR work
for both big endian and little endian
systems?</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">TO_LONG_PTR works only
with little endian, because we do not support PPC platform
</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Currently, there's no
need to extend it to support big endian</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=#339966 size=3><SPAN
style="FONT-SIZE: 12pt; COLOR: #339966"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Q3. How is the padded
space initialized?</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Inside sdp, all padded
space was initialized by class constructor (except one specific
case)</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In all other code, that
not C++, padded space was initialized by cl_memclr before setting the field
and before calling to ioctl procedure</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please, see my next
mail with examples from the code</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=navy size=3><SPAN
style="FONT-SIZE: 12pt; COLOR: navy"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial">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.)<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial">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?<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=green size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial">-
Sean<o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></BODY></HTML>