On Wed, Oct 19, 2016 at 11:59:26AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 19, 2016 at 10:28:36AM -0700, Adit Ranadive wrote:
>
> > > Requiring installed super updtodate kernel headers isn't going to
> > > help development. It would be good to keep a copy of the kernel
> > > headers in the rdma-core repo, similar to what most kernel tools
> > > tied to bleeding edge ABIs do.
> >
> > Thanks for the heads up. I had a few questions regarding the ABI stuff.
> > What happens in case of providers that arent part of the kernel as yet?
> > I would like to send out a pull request soonish for libpvrdma. I would
> > need to include the abi files in that request since cmake would fail.
>
> Follow the pattern rxe is using:
>
> CHECK_INCLUDE_FILE("rdma/rdma_user_rxe.h" HAVE_RDMA_USER_RXE)
> RDMA_DoFixup("${HAVE_RDMA_USER_RXE}" "rdma/rdma_user_rxe.h")
>
> Which uses the compat header file in
> buildlib/fixup-include/rdma-rdma_user_rxe.h, which must be a
> byte-for-byte copy of the kernel header.
I see that rxe still has a rxe-abi header in the providers/rxe folder.
Would that also move to the kernel as part of the conversion?
One of the things I'm unclear about what happends to the IBV structs
included in the user-level ABI headers, for example, the ibv_get_context_resp
here:
https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4-abi.h#L48
Since these are not present in the kernel, how would the libibverbs/core
uverbs stack handle this? Would there be forthcoming changes for that too?
> > Or do you want me to wait till Doug adds the PVRDMA driver to the tree?
>
> FWIW, we can't take a rdma-core provider until the kernel side is
> accepted, but you can certainly start the process now and get it to an
> OK state. Doug will be able to take both parts simultaneously.
>
Makes sense.
Thanks,
Adit
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
