Note that the DDK compiler has a bug related to handling 64-bit byte swaps. This is what prompted me to move to the WDK, as I was running into issues with 32/64 support (but no compiler error, just bad assembly).
-Fab From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tzachi Dar Sent: Wednesday, April 30, 2008 12:04 PM To: Smith, Stan; Hefty, Sean; Fab Tillier; Alex Naslednikov; Ishai Rabinovitz Cc: [email protected] Subject: RE: [ofw] WDK build environment migration thoughts Once we are sure that the new compiler works well, we should be able to abandon the DDK build. Thanks Tzachi ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Stan Sent: Wednesday, April 30, 2008 9:09 PM To: Hefty, Sean; Fab Tillier; Alex Naslednikov; Ishai Rabinovitz Cc: [email protected] Subject: RE: [ofw] WDK build environment migration thoughts ________________________________ From: Hefty, Sean Sent: Wednesday, April 30, 2008 10:41 AM To: 'Fab Tillier'; Alex Naslednikov; Smith, Stan; Ishai Rabinovitz Cc: [email protected] Subject: RE: [ofw] WDK build environment migration thoughts Once we confirm that building in the WDK works, is there any reason to keep supporting the DDK? I would expect support for the DDK should only be required while some components don't build under the WDK. I say absolutely not. Supporting the DDK means another at least another dozen builds that must all be tested. WDK is the 'supported' MS path -cut the past loose, move forward. <stan> It sounds like the __ptr64 patch failed to meet its objective if 32/64 support is broken. Just deleting the __ptr64 attribute would have accomplished the same end result and been 'cleaner'. I agree. Also, in the future please make patches more digestible - there's no reason ConnectX bug fixes should have been part of this - they should have been a separate check in. Having so many changes intermingled, while easier for you to publish, makes it *much* harder to digest. Likewise, the __ptr64 change should have been done independently of the WDK changes (especially since it introduced a regression). Your patch touched 3500+ lines of code. Just because SVN completely sucks for patch management doesn't mean that we need to make patch blob check-ins standard practice. We really need to look at alternative tools for Windows that make this easier for developers. Wasn't Mellanox testing git internally? What about bitkeeper, is that any better? - Sean
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
