On Mon, 2006-04-10 at 16:23, Roland Dreier wrote: > Hal> It certainly is more deterministic if there is an ABI version > Hal> change in that the errors can be disambiguated better but is > Hal> it required if an ioctl is added or alternatively > Hal> rmpp_version bit is "stolen" ? > > I'm pretty confused. What would the ioctl do? Return a bit saying > whether or not dual-sided RMPP is supported?
Yes. > What would happen if an > old app that didn't know about dual-sided RMPP ran and didn't perform > the ioctl? Nothing. An old app wouldn't do dual sided RMPP so it doesn't need to know. It's only a new app which might want to do DS RMPP which needs to know. > I guess this isn't really an ABI change -- old binaries continue to > run as long as they don't try dual-sided RMPP (which doesn't work now). > So maybe the answer is /sys/class/infiniband_mad/dual_sided_rmpp? > > An ioctl for something that is not attached to a file descriptor isn't > really the right thing. Yes, a file based approach is another way. Sean made me realize that this capability may not be so binary per machine due to vendor class 2. I need to think more on how this would be handled (burned into the RMPP core or a loadable kernel table seems like the only ways now; I would like something more flexible in the IBA spec (self identifying dual sided operations)). -- Hal > - R. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
