On Tue, May 31, 2005 at 02:03:06PM -0700, Tom Duffy wrote: > On Sat, 2005-05-28 at 09:13 +0200, Christoph Hellwig wrote: > > On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote: > > > 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. > > As one of the people trying to clean up kDAPL, I would like to know what > you think, from a design philosophy, is wrong with it. We *can* correct > any daim bramaged parts.
kDAPL is supposed to serve two needs: (1) provide an unified API for different RDMA transports (2) provide various higher level helpers as such it's largely duplicating what a proper RDMA stack should be. For (1) doing a proper RDMA stack should solve thing, and the discussion how to do it is already ongoing on this list. Once we have proper RMDA stack that part of KDAPL isn't needed at all anymore. The second is more interesting and there's indeed the need for some higher level helpers than the API at the level of the current OpenIB code offers. But having a separate layer, with different data structures, provider registration and a totally different API for that is utter nonsense. Instead the higher level helpers should operate on the same datastructures as the RDMA stack, or build new ones ontop of that. In addition some of the abstractions don't make much sense, the event handling has already been mentioned. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
