a defect between linker and module
bycn82
bycn82 at gmail.com
Sun Feb 8 05:05:35 PST 2015
*Hi,*
*during the re-factoring the ipfw2 module, i want to add a logic to
determine whether the module is allowed to be loaded into system. so i
added a piece of code in MOD_LOAD.*
*but if i create a test module with below code in "modevent"*
* switch (type) { case MOD_LOAD:
err = EEXISTS; break; case
MOD_UNLOAD: break; default:that means
it will do nothing just return "load error" and the error code is "file
exists" or "module exists".so when we loaded it , the module will not be
loaded. but when we run kldstat, we can see the module named
registered.below is what I found.when we kldload AAA module, actually there
are kldload syscall ----- linker -------modulelinker_load_file
and linker_unload_file functions (in kern_linker.c)are used to load/unload
the module, it will register the name in an array named linker_files. (
when we kldstat, actually is printing this array, i think )and linker...
will call module_register ( in kern_module.c ). anway, the module was
loaded in function module_register_init line 112 of kern_modules.c
error = MOD_EVENT(mod, MOD_LOAD); if (error) { module_unload(mod); /*
ignore error */ module_release(mod); kprintf("module_register_init:
MOD_LOAD (%s, %lx, %p) error %d\n", so when the MOD_LOAD return error, it
will call module_unload and module_release.but this function was invoked by
the linker, and this function never return any information, so the linker
will never know what is going on inside the function.so the module is still
registered inside the linker_files. i did not spend much time on this, so
that is all about what i found. Regards,Bill Yuan*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20150208/bae3efa3/attachment.html>
More information about the Users
mailing list