<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<title>RE: [ofw] WDK build environment migration thoughts</title>
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<p><b><u><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial;font-weight:bold'>1. __ptr64 problem</span></font></u></b><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span
style='font-size:10.0pt;font-family:Arial'>signed pointer extension</span></font></u>
<font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>will
take place.</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>When
user code do operation like </span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>s_ptr
= &my_struct;</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>my_type*
__ptr64 ptr = s_ptr;</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>To
avoid signed pointer extension, PtrToPtr64() function should be used.</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>This
problem was described in ofw discussion, you can see also :</span></font><o:p></o:p></p>
<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'><a
href="http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx"><font
size=2 face=Arial><span style='font-size:10.0pt;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 size=3 face="Times New Roman"><span style='font-size:12.0pt'><a
href="http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html"><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html</span></font></a></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'> (posted by
Jan from OFW)</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Our
solution:</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>(like
my_type* __ptr64 ptr = PtrToPtr64(s_ptr); )</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>2.
So, we decided about another solution:</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'> All
__ptr64 occurrences were replaced by either:</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'> i)
TO_LONG_PTR(type, field) macro, when occurred inside structure</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>ii)
VOID_PTR64 macro otherwise (defined as void macro)</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>#define
CONCAT(str1, str2) str1##str2</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>#define
TO_LONG_PTR(type,member_name) \</span></font><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>
union { type member_name; uint64_t CONCAT(member_name,_padding) ; }<o:p></o:p></span></font></p>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'><o:p> </o:p></span></font></p>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>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 size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>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 size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'><o:p> </o:p></span></font></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;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 size=2 face=Arial><span style='font-size:10.0pt;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 size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'><o:p> </o:p></span></font></p>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>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 size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'><o:p> </o:p></span></font></p>
<p><b><u><font size=2 face=Arial><span style='font-size:10.0pt;font-family:
Arial;font-weight:bold'>2. Migration to WDK</span></font></u></b><o:p></o:p></p>
<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Main
issue here was to preserve on backward compatibility with DDK<o:p></o:p></span></font></p>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'><o:p> </o:p></span></font></p>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>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 size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>- Sean<o:p></o:p></span></font></p>
</div>
</div>
</body>
</html>