[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Christoph Hellwig]

On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
> Caitlin wrote, 
> >Both uDAPL and kDAPL were designed for *application* use.
> >Even kDAPL is more intended for use by a kernel daemon that
> >is loaded separately from the kernel than for use within
> >the kernel itself.
> 
> kDAPL is intended as a kernel-level API
> for RDMA enabled fabrics. As it was initially written,
> it does not meet the Linux coding style and that is why
> it is being totally reworked as we speak to meet that goal. 

The codingstyle alone isn't the problem.  The whole design philosophy
is rather odd.

> >An ideal API for use within the kernel would abstract as
> >much as possible (without requiring emulation), and then
> >have transport specific unions or enum values. It would
> >hide no control options, merely provide common controls
> >for common capabilities.
> 
> So for every new RDMA device type that comes along, you need to add a new 
> enum, and unions for device class specific stuff, etc. 
> Seems rather static and not easily extended. Not 
> to mention that testing nightmare when the thing has to support
> 20 different types of RDMA enabled devices.
> I think code like that could get pretty ugly pretty fast. 

read the _as much as possible_ above.  There's a reason you'll need
new ABIs for the socket interface aswell when adding new address
families.