Eliminating the DAT_RETURN detail information is a strange choice, but certainly within the realm of options available to any implementation. No DAPL consumer should rely on the more detailed information. It is strange because it may encourage people to code from uDAPL in order to get more detailed diagnostic information while generally you would expect a kernel client to have access to more detailed info.
However the proposal to merge some of the major error codes would make it impossible for a wrapper include file (such as kdat.h) to restore the full API for use by insmodded clients. Given both of those factors, I believe it makes more sense to preserve the full DAT_RETURN value (including detail error data) as an out parameter. kdat.h could then simply turn it into the functional return for compatability clients and there would be no loss of information. Either that or we could work out on a case by case basis how kdat.h would be able to restore the original error value. This may be possible with data in the struct, since multiple outstanding errors on a single object would not seem to be likely (or perhaps more appropriately worthy of providing detailed error diagnostics for, since it probably represents a totally hosed application). _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
