Thanks, the mandatory function and process MAD parts look reasonable,
but looking at this:

 > --- verbs.c  (revision 5839)
 > +++ verbs.c  (working copy)
 > @@ -78,6 +78,9 @@
 >  {
 >      struct ib_ah *ah;
 >  
 > +    if (!pd->device->create_ah)
 > +            return ERR_PTR(-ENOSYS);
 > +
 >      ah = pd->device->create_ah(pd, ah_attr);
 >  
 >      if (!IS_ERR(ah)) {
 > @@ -99,6 +102,9 @@
 >      u16 gid_index;
 >      int ret;
 >  
 > +    if (!pd->device->create_ah)
 > +            return ERR_PTR(-ENOSYS);
 > +
 >      memset(&ah_attr, 0, sizeof ah_attr);
 >      ah_attr.dlid = wc->slid;
 >      ah_attr.sl = wc->sl;

it seems that maybe we should just trust kernel consumers not to
create AHs on iWARP devices, which don't support UD.  You can prevent
userspace consumers from being able to call create AH/destroy AH by
just leaving them out of the mask of userspace operations.

Also, for the mandatory functions, maybe it makes sense to split the
checking up for IB devices and iWARP devices.  IB devices (right now
at least) have to have the create_ah and destroy_ah methods, because
the MAD layer uses them.  Conversely, there are probably some
CM-related functions that iWARP devices are required to have.

 - 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

Reply via email to