The need for a single unifying event disptaching method was *the* primary feedback received from VIA user when DAPL started. That included both kernel and user-mode applications, in fact one of the primary reasons why the DAT Collaborative was started was that there was no unrestricted API for VIA that could be used in the kernel.
As I stated earlier, kDAPL is designed for *applications* and was not really intended for use by the OS itself. As such it abstracts more than just the transport. If you wrip out the EVDs it isn't really "kDAPL" anymore. Having a stripped subset of kDAPL with a clearly different name that is *only* what is needed to abstract transport differences might be a really neat idea, and having it be otherwise compatible with kDAPL would also be good. But I'd suggest understanding why something is present before ripping it out. EVDs are there precisely because dealing with multiple callbacks and completion queues was universally found to be unwieldly and unfriendly to application developers. On 5/31/05, Libor Michalek <[EMAIL PROTECTED]> wrote: > > 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 > _______________________________________________ > 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 > _______________________________________________ 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