[openib-general] [PATCH 1/2] kDAPL: remove inline functions

[James Lentini]

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.