[openib-general] [PATCH] The ibv_cmd_* create functions need to set the context.

[Michael S. Tsirkin]

> Quoting Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH] The ibv_cmd_* create functions need to set the context.
> 
>  > I actually think this approach is a wrong one: context should be
>  > set in common code like ibv_create_ah, not in ibv_cmd_ which is
>  > a library function low level driver might or might not call.
>  > And certainly this kind of change does not seem appropriate for stable branch.
>  > 
>  > I think the proper thing is for low level driver not to assume that
>  > fields such as contex are intialized until create functions have returned.
>  > Steve, pls fix your low level driver not to rely on this.
> 
> Hmm, there's not really any good solution to this.  Really the problem
> is that the ibv_cmd_destroy_xxx functions assume the context is set in
> the object they are destroying.  But I don't want to change the
> signature of those functions at this point in the release cycle.
> 
> It's not really very pleasing for low-level drivers to have to know
> about the internal assumptions of ibv_cmd_destroy_xxx either.
> 
> I think what I'll do is the following:
>  - add the assignments to context back into ibv_create_ah() and so
>    on.  context will get assigned in two places but oh well.
>  - early in the libibverbs 1.2 cycle, change the signature of
>    ibv_cmd_destroy_xxx so that low-level drivers need to explicitly
>    pass in the context to use.

This might work.
However, I wonder about stable branch - is it wise for a provider
to depend on a specific libibverbs 1.0.x version?
Surely just working atround this by setting up context field
before destroy cmd makes more sense?

And if the providers implement the work-around anyway,
should we implement hacks to work-around this in libibverbs as well?

What I am trying to propose is delaying the whole change till 1.2,
and doing the work-around in provider lib for now.

-- 
MST