Hefty, Sean <sean.he...@intel.com> wrote: >> I'm trying to understand the way the user/kernel way of adding verbs >> is implemented... I wasn't sure, if/which specific kernel patch out >> of this series is matching this one?
> There are no matching kernel patches to this patch. This does not try to > provide any > direct support for out of tree kernel patches. Sean, maybe I wasn't clear here, I was referring to the XRC kernel patch series you were just sending yesterday for upstream review/acceptance... isn't that series + libibverbs/libmlx4/librdmacm compose a complete solution for XRC for (say) new applications (forget about apps written to other XRC APIs)? I'm trying to understand if/what is the framework you suggest to add new user space verbs. Basically, I wasn't referring to such new verbs as vendor extensions, but rather as new verbs we want to add at this and/or future points of time which didn't exist at the time the IB stack and specifically its kernel/user ABIs/APIs were written (couple of years ago...). I hope to better spell out my question now, is this section below still relevant as the answer? Or. > The closest this comes is reserving the upper 8-bits of any enum or other > value, which can be used to indicate vendor specific support. For example, > an out of tree kernel patch could define a new QP type and ABI command with > one of the higher bits set (rather than the next in series). An upstream > patch would remove these bits. This should make it possible for a vendor to > continue to support their out of tree changes even after that feature was > added to the mainline. Hopefully this makes sense. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
