On 6/3/05, Bob Woodruff <[EMAIL PROTECTED]> 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
