Peter Memishian wrote:
> 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?
Right. After modload() returns, the framework would then do the modhash
lookup it does now to find the right plugin structure to associate with
the MAC. The part I find kind of strange is that the filename of the
plugin module would need to be exactly the same as the ident string the
plugin uses to register. If the developer makes a mistake and those two
strings aren't identical, then there's no way for the framework to find
the plugin once it's registered (that would be a bug in the plugin anyway).
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
