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. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general