> The modunload() will get to the plugin's _fini() routine, which will try > to to a mactype_unregister(). mactype_unregister() will return EBUSY > since the reference count kept by the mac module for that plugin will be > non-zero. The plugin's _fini() will then return EBUSY, thus failing the > modload().
That seems like it could work. The whole registration mechanism feels a little weird now, though. The original idea was that the explicit linker directives ensured the relevant plugins were already mactype_register()'d by the time the mac_register() occurred -- but now we'd drive the mactype_register() from the mac_register(), which seems odd, though not necessarily wrong. I presume the framework will verify that doing the modload() in fact led to the plugin registering under the expected name? -- meem _______________________________________________ networking-discuss mailing list [email protected]
