[openib-general] [PATCH] kDAPL: cleanup dat/ a bit more

Caitlin Bestler caitlin.bestler at gmail.com
Fri Jun 3 09:13:25 PDT 2005


On 6/3/05, Bob Woodruff <robert.j.woodruff at intel.com> wrote:
> Catlin Wrote,
> >That approach is certainly applicable for OpenIB as well.
> >The key is recognizing the need for a transition plan.
> >Customers have DAT Providers installed now, they
> >cannot synchronize getting new DAT Providers from
> >their suppliers with a new Linux release. This is
> >especially true since OpenIB does not currently
> >define a verbs interface that is suitable for iWARP
> >vendors to use. So dat_ia_openv() needs to still
> >support existing dat_registry logic and existing
> >DAT_PROVIDERs, otherwise it is breaking
> >existing code.
> 
> Are you talking about user-mode DAT/DAPL or kernel mode.
> For user-mode, the DAT registry mechanism and the dynamic
> loading of shared libraries seems to work OK and I
> see no need to change it.
> 
> For kernel-mode the method for discovering RDMA (DAPL) providers,
> or having them register with an RDMA mid-layer should be something
> that fits in better with Linux.
> 
> my 2 cents,
> 
Customers are using insmod to load DAPL Providers today, and
then using the registry to find them. That applies to both IB and
iWARP providers. The need for the registry reduces with each
step, but it doesn't instantly vanish and there should be a
transition plan.

Customers have a right to use insmod to load DAPL Providers,
especially if the DAPL Provider is under a GPL license. But
the fact that it is under a GPL license does not guarantee
that it has been forwarded t kernel.org for inclusion in the
mainline.

The transition plan might be as simple as *not* exporting
the dat_ia_openv symbol outside of the kernel until the
internal routine is ready to support legacy Providers or
there is no longer a need for Legacy Providers. The
consumer could simply insmod the existing DAT
Registry and the existing DAT Provider and make
no-use of the in-kernel code.

But that is the customer base that the kdAPL code
on sourceforge is supporting today. It would be strange
to take that code and break the applications that it was
created to support.



More information about the general mailing list