On 5/13/05, James Lentini <[EMAIL PROTECTED]> wrote: > > caitlin> DAT_RETURN serves two distinct purposes: it is an immediate return > caitlin> to a kernel specific caller, and it is a standardized error encoding > for > caitlin> clients outside of the linux kernel (loadable modules and or proxied > caitlin> user consumers). > caitlin> > caitlin> Even if the functional return to in-kernel clients is converted to > comply > caitlin> with kernel coding conventions, the information currently encoded > caitlin> in the DAT_RETURN needs to be deliverable to DAPL clients that > caitlin> are outside of the linux kernel. > > DAPL clients outside the linux kernel, userspace clients, should use > the uDAPL API. No changes are being proposed for the uDAPL API. >
What about kernel clients that are compiled separately from the kernel that want to be OS neutral and use kdat.h as published by the DAT Collaborative? Secondly, many routines are identical in user and kernel (in fact the common directory is bigger than either the udapl or kdapl directory on the sourceforge implementation) requiring that this code be maintained in parallel for the kernel and partner udapl librarires seems like a lot of extra long term work. _______________________________________________ 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
