Sean Hefty wrote: > Or Gerlitz wrote: >> Can you clarify what do you mean "(ABI) conflict with OFED releases"? >> Is an issue with someone wishing to work with OFED user space and IB >> code from upstream kernel?
> Yes - there could be issues there. As long as OFED provides kernel IB code you need not support the above config. >> The approach i suggest is: it makes sense to take some care not to >> create too much non working scenarios... however the upstream push >> process must **not** be restricted by the existence of OFED. > I agree with this. cool. >> Specifically, can you push rhe rdma_establish() ***kernel*** API >> support which was integrated into OFED 1.1 as a bug fix for 2.6.19 ? > Yes, but I'd like a user of it to go in at the same time. I don't think this is possible nor its required. The thing is that the only in-tree consumer of the cma code is the iser initiator which implements the active side of an rdma connection. As such it does not call rdma_accept() nor it can be modified to call rdma_establish(), so the _establish() call can be merged during bug fixes window similarly as the _accept() call has been merged during feature window. If you find it problematic to merge it for 2.6.19 i think you should demand ***removing*** the rdma_establish() call from OFED 1.1 as this puts the kernel code in second place relative to OFED and violates another guideline: OFED uses ***kernel IB code***, where "kernel IB code" stands for code that has been merged into Linus tree, or is at some branch of Roland's tree (or your tree when you have such...), or at the -mm tree etc. Or. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
