Re: [PATCH rdma-next V2 5/5] IB/core: Integrate IB address resolution module into core

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

On Mon, May 16, 2016 at 02:39:10PM -0400, Doug Ledford wrote:
> On 05/16/2016 02:27 PM, Jason Gunthorpe wrote:
> > On Mon, May 16, 2016 at 01:42:34PM -0400, Doug Ledford wrote:
> >> Can you build netlink in and then init the ib_addr module after the
> >> netlink init is complete?  Wouldn't that resolve the dependency ordering
> >> issue without changing the module names?
> > 
> > Why are you so worried about ib_addr's module name? Is that actually
> > hand loaded instead of relying in the implicit dependencies???
> 
> It's hand unloaded.  Depending on the release of software you are
> talking about, the init script has the ability to unload/reload the IB
> stack.  In that case, it has to know about ib_addr so that it can unload
> after ib_core.  I should know, when the order changed from ib_core first
> and ib_addr second to the opposite it broke the Red Hat init script for
> a release, including all the bug reports about the rdma stack failing to
> shut down properly because it was unloading modules in the wrong order.
> This falls in the same category of a lot of other things: you don't
> break user space if you don't have to.

I think the reason that this thread fails to die is our trouble to
understand if code refactoring is enough justification to get rid of all
these modules.

All guides/scripts which I saw, instructs to load all these ib_...
modules together and it looks redundant to have such large number of
them [1].

[1]
http://www.rdmamojo.com/2014/11/08/working-rdma-ubuntu/#Starting_the_RDMA_services

> 
> > Is failure to load a module going to break any existing scripts?
> > 
> > Worse comes to worse, just make dummy empty ib_addr.ko, but
> > I've never seen that in-kernel before.
> > 
> > Jason
> > 
> 
> 
> -- 
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
> 
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]