<!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" xmlns:v =
"urn:schemas-microsoft-com:vml"><HEAD><!--[if !mso]>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
font-family: Tahoma;
}
@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: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
page: Section1
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</STYLE>
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Jan Bottorff
[mailto:jbottorff@xsigo.com] <BR><B>Sent:</B> Tuesday, February 20, 2007 9:58
AM<BR><B>To:</B> Yossi Leybovich; ofw@lists.openfabrics.org<BR><B>Subject:</B>
RE: [ofw] port_attr structure<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I’d like to suggest
that we try to have STABLE API interfaces to the IB stack. What I mean by
stable is that IB clients will continue to work with new revisions of the IB
stack. Currently, there are a number of structures that are used as parameters
to IB functions. If you add a field to those structures, the size changes in a
new build. This means clients (kernel mode clients of the IBAL interface are
what I work with) are tied to exact revisions of the IB stack. Even worse,
there are no version or size attributes in many structures, and I offhand
don’t know of a way for a client to even query the IB stack for a build
revision. This means if I don’t compile my IB clients with the exact build
that is present at runtime, I may be corrupting memory, and not know it.
<BR><FONT color=#0000ff><SPAN class=099131508-20022007>[Yossi
Leybovich] I agree with the need of stable API, but as the WinIB
stack is under heavy development we encounter the need to add missing function
and fields to structures.</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN class=099131508-20022007>For example the IB spec changed
the mad packets lately to spec 1.2 and we wanted to update our stack .Or the
FMR we wanted for storage clients</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN class=099131508-20022007>I will be happy to follow your
guidelines to make the changes more compatible with IBAL
clients</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some simple areas
that would help preserve revision compatibility would
be:<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><![if !supportLists]><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="mso-list: Ignore">1)<SPAN
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"
Roman?? New Times><FONT size=2>
</FONT></SPAN></SPAN></SPAN></FONT><![endif]><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Have a function to
allocate memory in non-paged pool or query the size of assorted structures.
This would allow clients to allocate structure parameters without having
compiled in sizeof values. <BR><FONT color=#0000ff><SPAN
class=099131508-20022007>[Yossi Leybovich] That is done in query_ca_attr
and help us in the past to add vendor specific values, and you right we should
add this to the other
queries. </SPAN><o:p></o:p></FONT></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P><![if !supportLists]>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="mso-list: Ignore">2)<SPAN
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"
Roman?? New Times><FONT size=2>
</FONT></SPAN></SPAN></SPAN></FONT><![endif]><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Have a size or
version field in structures that are passed as parameters. This would allow
both the IB stack and clients to at least know if there was a version skew
problem, instead of corrupting memory. When adding new fields, put them at the
END. If fields become orphaned, don’t’ take them out, just rename them to
orphanedField1 or something. LOTS of the Microsoft API’s use this strategy to
preserver upward compatibility. In an ideal world, I’d actually not let
clients have direct access to fields; I’d have an object oriented function
interface to get and set values. There might (or might not) be cases where
performance is so critical, using setter/getters degrades performance, and in
those specific cases alternatives might be appropriate (like a query of the
field offsets, which a client can cache and use to directly access the
fields). This could be turned into an inline function that queries the field
offsets not yet cached, and then does the pointer math and the value
assignment. From a source code viewpoint, it could look like
SetConnectAttributes(ibalHandle, connectStructurePtr, value1, value2, value3).
Trying to architect things based on an ideal, and then finding solutions to
special cases when the ideal has a tradoff is often a good strategy.<BR><FONT
color=#0000ff><SPAN class=099131508-20022007>[Yossi Leybovich] In most of
the mad structure we use getter/setter this was done because the IB
spec was evolving and many field where changed/added to the
structures.</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN
class=099131508-20022007> But we
don't have setter/getter to most of the verb
structures.</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN
class=099131508-20022007> IBAL
does not have version on each structure but on the whole
interface.</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN
class=099131508-20022007> We should
change the version of the interface each time we change/add function or
change one of the structure in the interface files (i.e ib_types.h
....)</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><![if !supportLists]><FONT
face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="mso-list: Ignore">3)<FONT face="Times New Roman" size=1><SPAN
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"
Roman?? New Times>
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=Arial color=navy
size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Don’t
add new error codes in the MIDDLE of the enumeration, as it causes previous
values to be reassigned and breaks binary compatibility. If you want to group
things, then explicitly assign values in a group in the enumeration
definition. I’d actually prefer a single error code namespace. Right now I
translate all the overlapping IB error enumerations into a single unique
custom NTSTATUS. I frequently DO want to return error details up the call
chain, but don’t want to return multiple error types in parallel (which is
what I would have to do to tell the different between say a remote reject and
a NTSTATUS value for allocation failure in a connect function if I don’t map
IB errors into a single NTSTATUS namespace). <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P><![if !supportLists]>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="mso-list: Ignore">4)<SPAN
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"
Roman?? New Times><FONT size=2>
</FONT></SPAN></SPAN></SPAN></FONT><![endif]><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please be careful
about what #includes are required by clients. For example, some of the API’s
(I believe inline ones) use complib functions that are built as part of the IB
stack. At the moment, the IB stack will not compile under the 32-bit checked
WDK 6000/6001 compiler because the compiler seems unable to cope with a
function pointer in a structure with a __ptr64 attribute. We would like to be
using the WDK, but basically can’t, because our kernel clients MUST be linked
with a matching build of the IB stack (i.e. an IB stack compiled with the
WDK), and we can’t mix versions because some of the API’s need complib
functions.<BR><FONT color=#0000ff><SPAN class=099131508-20022007>[Yossi
Leybovich] Complib is historical library from the time IBAL was targeted
to Linux and Windows. The IB stack use complib all over the
code (spinlocks,events...)</SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN
class=099131508-20022007> So I don't
see how we can prevent from including complib </SPAN></FONT></SPAN></FONT></P>
<P class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT
color=#0000ff><SPAN
class=099131508-20022007> We
use to link complib dynamically but we move it to link statically into
ibbus.sys and ibal.dll </SPAN><o:p></o:p></FONT></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal
style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><![if !supportLists]><FONT
color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN
style="mso-list: Ignore">5)<SPAN
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"
Roman?? New Times><FONT size=2>
</FONT></SPAN></SPAN></SPAN></FONT><![endif]><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You might want to
consider updating the IBAL QUERY_INTERFACE version number if ANY structure or
error value changes in an incompatible way. At least then, clients can detect
a version problem, instead of the system crashing when memory is corrupted.
Generally in the past, I believe this version number tended to only get
updated if the interface function pointer array was updated. Changing a
parameter structure doesn’t change the source definition of the interface, but
very much can change the binary definition.<BR><FONT color=#0000ff><SPAN
class=099131508-20022007>[Yossi Leybovich] Agree , I will do
that. </SPAN><o:p></o:p></FONT></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal><FONT color=navy><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I’m not trying to
stifle ongoing development and improvement in the IB stack. I am trying to
discuss ways the IB stack can evolve that will cause fewer problems for those
of us using the IB stack for commercial products. Decoupling the IB stack
build version from IB client build version would help a lot. This would take a
clear definition of the binary API, and a little bit of ongoing developer
discipline.<BR><FONT color=#0000ff><SPAN class=099131508-20022007>[Yossi
Leybovich] Pls note that we are on the process of getting WHQL on the
WInIB stack and I hope that after we will get the signature the changes
will be less frequently </SPAN><o:p></o:p></FONT></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Jan
Bottorff<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Windows Systems
Architect<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Xsigo
Systems<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><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 class=MsoNormal><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 class=MsoNormal><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 class=MsoNormal><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 class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT
face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">
ofw-bounces@lists.openfabrics.org [mailto:ofw-bounces@lists.openfabrics.org]
<B><SPAN style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Yossi
Leybovich<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday,
February 18, 2007 4:52 AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B>
Fab Tillier<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B>
ofw@lists.openfabrics.org<BR><B><SPAN
style="FONT-WEIGHT: bold">Subject:</SPAN></B> [ofw] port_attr
structure</SPAN></FONT><o:p></o:p></P></DIV>
<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=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I want to add more
info to the port_attr structure (like link width enable, link width
enable).<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I notice that the
port_attr include only specific fields from the port info structure of the IB
spec.<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Is there any reason
why the port_attr structure in IBAL is different from the IB spec port info
(or at least include all its fields)<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Yossi
<o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>