On 05/18/2016 12:41 AM, Leon Romanovsky wrote: > 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 I've never heard of rdmamojo before...interesting. Anyway, it probably is true that the number of modules is superfluous. I'm not arguing against that. >> >>> 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@xxxxxxxxxx> >> GPG KeyID: 0E572FDD >> >> > > -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
