Hi Hal, On 06:18 Mon 15 Oct , Hal Rosenstock wrote: > > I don't recall as this is from a very very long time ago but in looking > at this, I agree with your assessment that it can be simplified (and > there appears to be no real need for what is contained in struct Port > other than the fd). The only downside I see is the subtle change in the > public umad_ APIs changing int portid -> int fd.
There is no API change at all - umad_open_port() still return unique integer descriptor as it was before. Here we are only changing undocumented (at least I'm not able to find any public description about what umad_open_port() should return) behavior of this API (by replacing mad device number as umad_open_port() return value, but if we want to support multiple open()s there is no choice - device number is not suitable for this). > I suppose all the tools > would continue to work without change here even if libibumad were > changed underneath it, right ? Right. > BTW, when you do this, the umad man pages > should all be updated for this change. I see only that umad_open_port.3 should be fixed - it says that return value is "0" on success, which is not correct anyway. Not really related to the patch. Do you see another places to fix in man? Sasha _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
