Got it. Thanks. > -----Original Message----- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Friday, August 12, 2005 11:11 AM > To: Tom Tucker > Cc: [email protected] > Subject: Re: [openib-general] IB Driver Initialization of FMR methods > > >>>>> "Tom" == Tom Tucker <[EMAIL PROTECTED]> writes: > > Tom> I've noticed that in the IB driver, the FMR methods are not > Tom> initialized if the XX_FLAG_FRM bit is not set in the device > Tom> structure. My assumption at this point is that these methods > Tom> are not present if they are not supported by the device. > > Tom> What's confusing is that the verbs do not check if the > Tom> function ptr is null when involking the underlying method. I > Tom> would have expected, that a method would be initialized that > Tom> returned ENOSYS in this case. Any explanation as to the > Tom> intended design point for FMR initialization would be greatly > Tom> appreciated. > > I think you must have looked in the wrong place. In > drivers/infiniband/core/verbs.c, ib_alloc_fmr() starts with: > > struct ib_fmr *ib_alloc_fmr(struct ib_pd *pd, > int mr_access_flags, > struct ib_fmr_attr *fmr_attr) > { > struct ib_fmr *fmr; > > if (!pd->device->alloc_fmr) > return ERR_PTR(-ENOSYS); > > so if alloc_fmr is not set, the caller will get -ENOSYS. > > We do assume that if the device implements alloc_fmr(), it will > implement the other FMR methods. This isn't enforced by any code, > since it doesn't seem worth checking for something that is an obvious > bug, and that will cause an immediate and easy-to-diagnose oops. > > - 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
