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

[Libor Michalek]

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.

  Well, from a kernel API design philosophy the evd is somewhat odd.
The whole idea behind the event model seems a bit convoluted. First
multiplex a wide variety of events from the provider into a single event
queue, and then have an API so the consumer can tell what type of event
they actually have and can still receive the event notification in the
provider's context.

  This seems to be a lot of work to first hide useful information, but
also not loose the information in case the consumer really does want it.
It appears to be a case of a decent userspace idea that doesn't make
much sense in the kernel. Why is it there? I imagine it's to abstract a
variety of OS kernels, which was one of the goals of the design.

  Also, I realize it's just an implementation detail, but I've got a 
number of issues with ATS.


-Libor