[ofw] WDK build environment migration thoughts
Tzachi Dar
tzachid at mellanox.co.il
Thu May 1 15:12:59 PDT 2008
Applied in version 1109.
Thanks
Tzachi
________________________________
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Alex Naslednikov
Sent: Thursday, May 01, 2008 7:48 PM
To: Alex Estrin; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration thoughts
Fixed.
Index: core/bus/kernel/ib_bus.inf
===================================================================
--- core/bus/kernel/ib_bus.inf (revision 1106)
+++ core/bus/kernel/ib_bus.inf (working copy)
@@ -6,8 +6,8 @@
Signature="$Windows NT$"
Class=System
ClassGuid={4D36E97D-E325-11CE-BFC1-08002BE10318}
-Provider=%MTL%
-DriverVer=08/12/2007,1.4.0.2041
+Provider=%OPENIB%
+DriverVer=03/08/2006,1.0.0000.614
CatalogFile=ib_bus.cat
; ================= Device Install section =====================
@@ -61,7 +61,6 @@
[Manufacturer]
%OPENIB% = Ibbus.DeviceSection,ntx86,ntamd64,ntia64
-%MTL% = Ibbus.DeviceSection,ntx86,ntamd64,ntia64
%SST% = SST.DeviceSection,ntx86,ntamd64,ntia64
[Ibbus.DeviceSection]
@@ -87,18 +86,24 @@
%VEx.DeviceDesc% = Iou.DDInstall,IBA\V00066aP0058
%FVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00dd
%EVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00de
+%BC2FC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e0
+%BC2GE.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e1
[SST.DeviceSection.ntamd64]
%VFx.DeviceDesc% =
Iou.DDInstall,IBA\V00066aP0060,IBA\V00066aP0010
%VEx.DeviceDesc% = Iou.DDInstall,IBA\V00066aP0058
%FVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00dd
%EVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00de
+%BC2FC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e0
+%BC2GE.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e1
[SST.DeviceSection.ntia64]
%VFx.DeviceDesc% =
Iou.DDInstall,IBA\V00066aP0060,IBA\V00066aP0010
%VEx.DeviceDesc% = Iou.DDInstall,IBA\V00066aP0058
%FVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00dd
%EVIC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00de
+%BC2FC.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e0
+%BC2GE.DeviceDesc% = Iou.DDInstall,IBA\V00066aP00e1
[Ibbus.DDInstall.ntx86]
CopyFiles = Ibbus.CopyFiles
@@ -185,18 +190,20 @@
[Strings]
OPENIB = "OpenIB Alliance"
-MTL = "Mellanox Technologies Ltd."
SST = "SilverStorm Technologies"
-Ibbus.DeviceDesc = "Mellanox InfiniBand Fabric"
+Ibbus.DeviceDesc = "InfiniBand Fabric"
VFx.DeviceDesc = "SilverStorm VFx"
VEx.DeviceDesc = "SilverStorm VEx"
FVIC.DeviceDesc = "SilverStorm FVIC"
EVIC.DeviceDesc = "SilverStorm EVIC"
-Iou.DeviceDesc = "Mellanox InfiniBand I/O Unit"
-Ibbus.ServiceDesc = "InfiniBand Bus Driver"
-Ibal.ServiceDesc = "InfiniBand Access Layer"
-Iou.ServiceDesc = "InfiniBand I/O Unit Driver"
-DiskId = "Mellanox InfiniBand Access Layer installation disk"
+BC2FC.DeviceDesc = "QLogic InfiniBand Fibre Channel Bridge
Module"
+BC2GE.DeviceDesc = "QLogic InfiniBand Ethernet Bridge Module"
+
+Iou.DeviceDesc = "InfiniBand I/O Unit"
+Ibbus.ServiceDesc = "OpenIB InfiniBand Bus Driver"
+Ibal.ServiceDesc = "OpenIB InfiniBand Access Layer"
+Iou.ServiceDesc = "OpenIB InfiniBand I/O Unit Driver"
+DiskId = "OpenIB InfiniBand Access Layer installation disk"
SPSVCINST_NULL = 0x0
SPSVCINST_ASSOCSERVICE = 0x00000002
SERVICE_KERNEL_DRIVER = 1
Index: hw/mthca/kernel/mthca.inf
===================================================================
--- hw/mthca/kernel/mthca.inf (revision 1091)
+++ hw/mthca/kernel/mthca.inf (working copy)
@@ -5,9 +5,9 @@
Signature="$Windows NT$"
Class=InfiniBandHca
ClassGUID={58517E00-D3CF-40c9-A679-CEE5752F4491}
-Provider=%MTL%
+Provider=%OPENIB%
; must be synchronized with MTHCA_DEV.H
-DriverVer=08/12/2007,1.4.0.2041
+DriverVer=03/08/2006,1.0.0000.614
CatalogFile=mthca.cat
; ================= Destination directory section
=====================
Index: tests/alts/kernel/alts.inf
===================================================================
--- tests/alts/kernel/alts.inf (revision 1106)
+++ tests/alts/kernel/alts.inf (working copy)
@@ -26,7 +26,7 @@
ClassGUID=%HcaClassGuid%
Provider=%Vendor%
CatalogFile=infiniserv.cat
-DriverVer=12/21/2006,1.0.0000.566
+DriverVer=03/08/2006,1.0.0000.614
; ================= Destination directory section
=====================
Index: ulp/ipoib/kernel/netipoib.inf
===================================================================
--- ulp/ipoib/kernel/netipoib.inf (revision 1106)
+++ ulp/ipoib/kernel/netipoib.inf (working copy)
@@ -6,26 +6,26 @@
Signature = "$Windows NT$"
Class = Net
ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318}
-Provider = %MTL%
-DriverVer=08/12/2007,1.4.0.2041
+Provider = %OPENIB%
+DriverVer=03/08/2006,1.0.0000.614
CatalogFile=ipoib.cat
[Manufacturer]
-%MTL% = MTL,ntx86,ntamd64,ntia64
+%OPENIB% = OPENIB,ntx86,ntamd64,ntia64
[ControlFlags]
ExcludeFromSelect = IBA\IPoIB
-[MTL]
+[OPENIB]
; empty since we don't support W9x/Me
-[MTL.ntx86]
+[OPENIB.ntx86]
%IpoibDesc% = Ipoib.DDInstall, IBA\IPoIB ; Internet Protocol
over InfiniBand Adapter
-[MTL.ntamd64]
+[OPENIB.ntamd64]
%IpoibDesc% = Ipoib.DDInstall, IBA\IPoIB ; Internet Protocol
over InfiniBand Adapter
-[MTL.ntia64]
+[OPENIB.ntia64]
%IpoibDesc% = Ipoib.DDInstall, IBA\IPoIB ; Internet Protocol
over InfiniBand Adapter
[Ipoib.DDInstall.ntx86]
@@ -188,10 +188,9 @@
[Strings]
OPENIB = "OpenIB Alliance"
-MTL = "Mellanox Technologies Ltd."
-IpoibDesc = "Mellanox IPoIB Adapter"
+IpoibDesc = "OpenIB IPoIB Adapter"
IpoibServiceDispName = "IPoIB"
-IcsDisk1 = "Mellanox IPoIB Disk #1"
+IcsDisk1 = "OpenIB IPoIB Disk #1"
DIRID_SYSTEM = 11
DIRID_DRIVERS = 12
DIRID_SYSTEM_X86 = 16425
Index: ulp/srp/kernel/ib_srp.inf
===================================================================
--- ulp/srp/kernel/ib_srp.inf (revision 1103)
+++ ulp/srp/kernel/ib_srp.inf (working copy)
@@ -5,10 +5,10 @@
Signature="$Windows NT$"
Class=SCSIAdapter
ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}
-Provider=%MTL%
-DriverVer=12/21/2006,1.0.0000.566
-;CatalogFile=ib_srp.cat
+Provider=%OPENIB%
+DriverVer=03/08/2006,1.0.0000.614
+
; ================= Device Install section =====================
[DestinationDirs]
@@ -28,7 +28,6 @@
[Manufacturer]
%OPENIB% = SRP.DeviceSection,ntx86...0x1,ntx86,ntamd64,ntia64
-%MTL% = SRP.DeviceSection,ntx86...0x1,ntx86,ntamd64,ntia64
%SST% = VFx.DeviceSection,ntx86...0x1,ntx86,ntamd64,ntia64
[SRP.DeviceSection]
@@ -120,12 +119,11 @@
[Strings]
OPENIB = "OpenIB Alliance"
-MTL = "Mellanox Technologies Ltd."
SST = "SilverStorm Technologies"
-SRP.DeviceDesc = "Mellanox InfiniBand SRP Miniport"
+SRP.DeviceDesc = "InfiniBand SRP Miniport"
VFx.DeviceDesc = "SilverStorm VFx I/O Controller"
-SRP.ServiceDesc = "InfiniBand SRP Miniport"
-DiskId = "Mellanox InfiniBand SRP installation disk"
+SRP.ServiceDesc = "OpenIB InfiniBand SRP Miniport"
+DiskId = "OpenIB InfiniBand SRP installation disk"
InternalBus = 0
PNPBus = 15
SPSVCINST_NULL = 0x0
________________________________
From: Alex Estrin [mailto:alex.estrin at qlogic.com]
Sent: Thursday, May 01, 2008 3:08 PM
To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration thoughts
I've noticed unnecessary changes in ib_bus.inf:
branding changed from OpenIB Alliance to Mellanox.
removed hardware IDs and device descriptors for QLogic Fibre
Channel and Ethernet bridge modules.
Rebranding is also noticed in ib_srp.inf, netipoib.inf
Thanks,
Alex.
________________________________
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Alex Naslednikov
Sent: Wednesday, April 30, 2008 4:20 AM
To: Alex Naslednikov; Smith, Stan; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment migration
thoughts
Hello,
I committed our WDK and __ptr64 patch into WinOF trunk,
and WinOF and WinIB trunks were synchronized again.
You can find below some further explanations :
1. IBAL compiles now with WDK6001.18001. According to
Microsoft, it should be the last and official release.
We preserved the backward compatibility with DDK, but
some intermediate versions of WDK may be incompatible
2. Please, be aware that one has to change WinOF modules
that aren't in WinIB stack (like additional ulps : udapl, vnic etc.)
according to new methodology
Also, I'd like to point your attention, that these
modules will work as is on homogeneous systems (x86, x64), but not on
mixed systems (x86 application on x64 kernel)
In addition, Microsoft fixed an internal compiler bug
when compiling modules with long (__ptr64) pointers on functions
(occurred only in x86 CHECKED environment).
So, you should not have problem with compilation after
adjusting makefiles
3. This revision contains:
3.1. All bugfixes from WinOF trunk, from rev. 939 to
1067
3.2. Mellanox __ptr64 solution and WDK poring, starting
from rev. 2164
3.3. All bugfixes and patches from connectx branches
(both Mellanox and WinOF)
It was a large amount of code to be merged from 4
different svn trees (trunk and connectx branch in WinOF, and trunk and
connectx branch in WinIB).
We will appreciate your code review, just to be sure
that we didn't forget to insert any minor patch or bug fix.
4. I carefully tested new trunk inside Mellanox, on
different platforms, both with DDK and WDK compilers. Please, update us
about every minor problem during your testing.
Thanks,
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
_____________________________________________
From: Alex Naslednikov
Sent: Monday, April 21, 2008 7:15 PM
To: Alex Naslednikov; 'Smith, Stan'; Ishai
Rabinovitz
Cc: 'ofw at lists.openfabrics.org'
Subject: RE: [ofw] WDK build environment
migration thoughts
Hi all,
I would like to repost my previous message, because I
haven't received yet your comments.
Our regression seems to be stable, so we are going to
commit the change into WinOF trunk the nearest time.
For you convenience, I also provide some typical changes
as a patch (attached to this mail). Please, read the explanation below
before - it will help you a lot.
Be aware that all the modules not contained in Mellanox
WinIB stack (like udapl, vnic) should be also changed according to this
methodology.
It is very large change, so I'll appreciate your time
and effort while reviewing the methodology and the patch itself.
Thanks,
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
_____________________________________________
From: Alex Naslednikov
Sent: Thursday, April 10, 2008 4:09 PM
To: 'Smith, Stan'; Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw] WDK build environment
migration thoughts
Hi all,
It's a good idea to clarify some points before
announcing Mellanox patch for WDK porting and __ptr64 problems.
Hope, these explanations will be informative enough and
not so long.
1. __ptr64 problem
Briefly speaking, this problem arises when copying 32bit
len pointer into 64bit len pointer. In this case, signed pointer
extension will take place.
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.
When user code do operation like
s_ptr = &my_struct;
my_type* __ptr64 ptr = s_ptr;
Than kernel will receive ptr with invalid upper bits
data (4 bytes FF).
To avoid signed pointer extension, PtrToPtr64() function
should be used.
Also, I found some other places where dangerous signed
pointer extension took place, even on 32bit kernel.
Yet another problem that arises with __ptr64 attribute
is internal compiler error (C1001) in WDK when using __ptr64 pointer to
function (callback)
This problem was described in ofw discussion, you can
see also :
http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx
<http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx>
http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html
<http://lists.openfabrics.org/pipermail/ofw/2007-July/001613.html>
(posted by Jan from OFW)
Our solution:
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.
(like my_type* __ptr64 ptr = PtrToPtr64(s_ptr); )
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
2. So, we decided about another solution:
All __ptr64 occurrences were replaced by either:
i) TO_LONG_PTR(type, field) macro, when occurred inside
structure
ii) VOID_PTR64 macro otherwise (defined as void macro)
#define CONCAT(str1, str2) str1##str2
#define TO_LONG_PTR(type,member_name) \
union { type member_name; uint64_t
CONCAT(member_name,_padding) ; }
Thus, we can both preserve on a uniform shapes of
structs in user and kernel and to avoid unsafe pointer arithmetic !
The patch now is much more readable, but it sill consist
of thousands lines.
2. Migration to WDK
Main issue here was to preserve on backward
compatibility with DDK
We were able to compile our stack with WDK, while the
main problems we found were :
1. WDK uses newer version of SDK (SDK Vista). So, when
using 2 or more versions of SDK on the same build machine, one has to
update
PLATFORM_SDK_PATH variable to point on the proper
version of SDK (for example,
PLATFORM_SDK_PATH=%sysdrive%:\PROGRA~1\MI2578~1\windows\v6.1)
2.verify.src script in WDK (new add-on) checks if your
SOURCES file is in appropriate format.
For example, you can't set implicitly path to system
.dll in TARGETLIBS, but to use USE_<MODULE_NAME> =1 macro
Example:
Old code :
....
TARGETLIBS= \
$(CRT_LIB_PATH)\msvcprt.lib\
$(SDK_LIB_PATH)\Ws2_32.lib\
$(TARGETPATH)\*\mtcr.lib
New code :
USE_MSVCRT=1
USE_NTDLL=1
TARGETLIBS= \
$(SDK_LIB_PATH)\Ws2_32.lib\
$(TARGETPATH)\*\mtcr.lib
3. Some other problems, like mulitple includes error in
.rc files, or problem with substituing more than one symbol constant
into string in Makefiles (some version of WDK)
Currently, we continue testing and will advertise these
patches right after the testing will finish
Naslednikov Alexander (a.k.a XaleX)
Windows Team
Mellanox Technologies
-----Original Message-----
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org
<mailto:ofw-bounces at lists.openfabrics.org> ] On Behalf Of Smith, Stan
Sent: Tuesday, April 08, 2008 4:10 PM
To: Ishai Rabinovitz
Cc: ofw at lists.openfabrics.org
Subject: [ofw] WDK build environment migration thoughts
Hello,
I strongly believe it would help the WinOF community
in transitioning to the WDK build environment if the connectX branch
(svn:gen1\branches\ConnectX) was used as a WDK build
environment staging grounds prior to merging the WDK modifications into
the mainline trunk.
This has been talked about before although it still (as
of last Friday) does not build using the latest WDK version.
One week prior to merging the WDK fixes into the
mainline trunk, if you were to push all the WDK fixes into the ConnectX
branch and then advertise on the ofw mailing list the availability of a
WDK build branch along with
1) how to build in the WDK environment,
which version of the WDK is required + a URL link
where to get the WDK.
2) An explanation of why and how the __ptr64
attributes were removed along with how
others should correct their codes containing
__ptr64 attributes.
3) updates to the WinOF wiki page describing how to
build in the WDK env.
Let this branch exist for one week, receiving feedback
from the list and then merge into the mainline trunk.
Using this approach is certainly community friendly and
may prevent developer surprises.
ConnectX branch availability dates plus when the actual
WDK fixes would be merged into the mainline trunk would be published
beforehand.
Thanks for your consideration,
Stan.
_______________________________________________
ofw mailing list
ofw at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
<http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080502/9c37da1e/attachment.html>
More information about the ofw
mailing list