<!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-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 class=052341018-21042008><FONT face=Arial size=2>Good questions
!</FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2>Q1. <SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#000000>Unless CONCAT is used elsewhere, I would not add that #define.
It’s too generic of a name.</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I put #ifndef around
this macro for the case it had been defined, but it's possible to rename it too,
say, CONCAT_STR </SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please, see my next
mail with the example of a patch</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#000000>Q2.<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></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><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></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Currently, there's no
need to extend it to support big endian</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Q3. How is the padded
space initialized?</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><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></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><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></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please, see my next
mail with examples from the code</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Q4. WDK
migration</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Code can be compiled
both in WDK and DDK. Of course, we carefully check it with our regression system
for all combination of platforms (x86/x64) and
environments</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial color=#000000 size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">XaleX</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=052341018-21042008><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT></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 8:09 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">
<P><B><U><FONT face=Arial size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">1. __ptr64
problem</SPAN></FONT></U></B><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Briefly speaking, this problem
arises when copying 32bit len pointer into 64bit len pointer. In this
case,</SPAN></FONT><U> </U><U><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">signed pointer
extension</SPAN></FONT></U> <FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">will take
place.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">When user code do operation like
</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">s_ptr =
&my_struct;</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">my_type* __ptr64 ptr =
s_ptr;</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Than kernel will receive ptr with
invalid upper bits data (4 bytes FF).</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">To
avoid signed pointer extension, PtrToPtr64() function should be
used.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Also, I found some other places
where dangerous signed pointer extension took place, even on 32bit
kernel.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Yet
another problem that arises with __ptr64 attribute is internal compiler error
(C1001) in WDK when using __ptr64 pointer to function
(callback)</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem was described in ofw
discussion, you can see also :</SPAN></FONT><o:p></o:p></P>
<P><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"><A
href="http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx"><FONT
face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx</SPAN></FONT></A><o:p></o:p></SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"><A
href="http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html"><FONT
face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html</SPAN></FONT></A></SPAN></FONT><FONT
face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> (posted by
Jan from OFW)</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Our
solution:</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(like my_type* __ptr64 ptr =
PtrToPtr64(s_ptr); )</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">2.
So, we decided about another solution:</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> All __ptr64 occurrences were
replaced by either:</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> i) TO_LONG_PTR(type, field)
macro, when occurred inside structure</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">ii)
VOID_PTR64 macro otherwise (defined as void macro)</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">#define CONCAT(str1, str2)
str1##str2</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">#define
TO_LONG_PTR(type,member_name) \</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> union { type
member_name; uint64_t CONCAT(member_name,_padding) ;
}<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Unless CONCAT is used
elsewhere, I would not add that #define. It’s too generic of a
name.<o:p></o:p></SPAN></FONT></P>
<P><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? How is the padded space
initialized?<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thus, we can both preserve on a
uniform shapes of structs in user and kernel and to avoid unsafe pointer
arithmetic !</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The
patch now is much more readable, but it sill consist of thousands
lines.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">IBAL uses typedefs
everywhere. Why couldn’t the typedefs be redefined as ‘UINT64’ instead of
struct _blah __ptr64? Compiled code shouldn’t notice the difference, and
we’d get compiler warnings for any casting errors, that we could then clean
up. It doesn’t seem like this would produce a patch that’s any bigger or
more difficult to read, but the resulting code would be cleaner than introducing
unnamed unions with potential padding that requires additional
initialization.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P><B><U><FONT face=Arial size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">2. Migration to
WDK</SPAN></FONT></U></B><o:p></o:p></P>
<P><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Main issue here was to preserve on
backward compatibility with DDK<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Personally, I don’t see
the need to be backward compatible with the DDK. Let’s just require the
latest WDK to build the drivers.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-
Sean<o:p></o:p></SPAN></FONT></P></DIV></DIV></BODY></HTML>