Just apply all the patches to your development branch without checking in and you'll get the same. You should be able to apply the 4 patches sequentially without issue.
-Fab > -----Original Message----- > From: Alex Naslednikov [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 9:56 AM > To: Alex Naslednikov; Fab Tillier; [email protected] > Subject: RE: [ofw] RE: [PATCH 1/4] Clean up MAC generation,add support for HP > GUIDs > > Hello all, > Following our discussion during WinOF meeting, I'd like to explain > better what we meant by "one final patch". > Of course, the division into small chunks should be preserved. > We just want to avoid bringing unnecessary noise into svn trunk, because > Fib's patch included "fix to the fix to the patch" > > Fab, we would like to ask you resend us the final version of your > patches again, > Thank You, > XaleX > > -----Original Message----- > From: Alex Naslednikov > Sent: Thursday, October 02, 2008 10:14 AM > To: 'Fab Tillier'; [email protected] > Subject: RE: [ofw] RE: [PATCH 1/4] Clean up MAC generation,add support > for HP GUIDs > > Hello Fab, > Thank you for your time for reviewing GUID patches. > Please, send again one final patch - there's no need to insert all these > patches into svn tree. > > XaleX > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier > Sent: Tuesday, September 30, 2008 10:01 PM > To: Fab Tillier; [email protected] > Subject: [ofw] RE: [PATCH 1/4] Clean up MAC generation,add support for > HP GUIDs > > > At this point, the mask_status could be IB_INVALID_GUID_MASK (in the > > current unpatched code). If one of the vendor-specific conversion > > functions returned IB_SUCCESS the code still returns > > IB_INVALID_GUID_MASK, which is wrong. In fact, even if the GUID has > > no known conversion function, the code will fall through to the > > locally administered MAC address generation, and then return > IB_INVALID_GUID_MASK anyway... > > Oy, so the plot thickens... The IB_INVALID_GUID_MASK error code isn't > actually an error - the code that checks for this value uses it to log a > entry in the event log, but expects the MAC to be generated anyways... > So it's an error that isn't an error... Ugh, talk about convoluted. It > would have been *really* helpful to have some comment that would inform > the reader of this totally counter intuitive behavior. > > Ok, so I'm going to fix up my 4th patch (again) to implement the > following behavior: > > 1. Ignore the registry GUID mask if there is a known conversion for a > GUID. This is especially needed in the receive path, as the GUID mask > code will potentially incorrectly generate a MAC address for a known > GUID - Mellanox, SilverStorm, and Voltaire GUIDs all would get > improperly generated. > > 2. Attempt MAC generation if a GUID mask is provided, only for the local > port GUIDs during adapter initialization. The remote port GUIDs (from a > received packet) should *not* use the GUID mask, as the local node has > no idea what the remote GUID formats are. > > 3. If a GUID mask is provided, fail adapter initialization if it is > invalid. > > -Fab > > > _______________________________________________ > ofw mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
