[openib-general] makiing ibverb.h transport neutral -- 2nd draft

[Sean Hefty]

Caitlin Bestler wrote:
> The overbloated union also works, but it has its own pains.
> I have no problem changing it back to the union approach on 
> either the forward and/or reverse path, if that is the consensus.
> Personally, I think using a different style for forware and
> reverse would be more confusing, that using a cast in response
> to an opcode is no more inherently suspect than selecting a
> union sub-variant in response to an opcode and that many or
> most applications will need to support multiple work completion
> sub-types anyway.

(Note that I'm just using rdma_poll_cq() as an example.  I didn't go into 
the other calls in as much detail.)

I'm not suggesting the use of unions everywhere.  I think that there's a 
problem defining a 256 byte structure that is likely to be declared on the 
stack so an application can call poll_cq in a transport independent fashion.

Reading a field in a structure and then casting the structure to a parent 
structure does not require any specific field layout.  Taking an input 
parameter to a function and casting it to a parent structure does.  For 
example, redefine struct ib_wc and move the common field to the end of the 
structure.

I don't have an issue with how post_send/post_recv would work; just pointing 
out that type checking is lost, which can lead to accessing invalid memory. 
  For example, an application cannot just define struct rdma_wc and then 
call rdma_poll_cq() and have it work.  This would result in stack 
corruption, yet matches the defined API.

- Sean