On Thu, 4 Aug 2005, Tom Duffy wrote:
On Thu, 2005-08-04 at 20:30 +0300, Or Gerlitz wrote:
This is almost exactly what is there now. Not really a change.
I don't like the multiple indirections to get to the function
table, but this can be simplified later.
Indeed, it can be simplified a little, but why not having this
simplification in the kdapl registry level ("dat") as it is in
ib_core calling ib_verbs and libibverbs calling libmthca, while the
verbs consumer does not have to go into those indirections at all
but rather just call a well understood/defined api? are you
suggesting to apply such a chance also to the verbs?
I don't understand what you mean? What change would happen in verbs?
I think Or is asking if similar changes should be made to the verbs
(i.e. should ib_alloc_pd() be remove and replaced in each verb's user
by device->alloc_pd(..), etc.). Is that right Or?
In kDAPL, the inline dat_* functions just perform a function call.
In the case of the verbs, there are some operations performed by the
verbs core in addition to calling the function. For
example, ib_alloc_pd() intiailizes the ib_pd fields in addition to
calling the device specific alloc_pd function.
Due to the additional functionality, I don't think this convention
would extend to the IB verbs.
In terms of kDAPL, I share Or's concern that this will make the API
harder for consumers to use. Picture someone who wants to use the
kDAPL API for the first time. Today that person would scan the kDAPL
header and see all of the functions available and get a pretty clear
picture of what each functions parameters are for just by looking at
the parameter names. We'd loose that "documentation" with this change.
With respect to the struct file_operations analogy, is a struct
file_operations embedded in any other structure besides struct file?
In kDAPL, the function table is embedded in several different objects.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
