[Asterisk-code-review] loader: Convert reload classes to built-in modules. (asterisk[master])
Corey Farrell
asteriskteam at digium.com
Wed Mar 7 20:11:37 CST 2018
Corey Farrell has posted comments on this change. ( https://gerrit.asterisk.org/8390 )
Change subject: loader: Convert reload_classes to built-in modules.
......................................................................
Patch Set 1:
(10 comments)
I should be able to get an updated posted in the next couple days.
https://gerrit.asterisk.org/#/c/8390/1/include/asterisk/module.h
File include/asterisk/module.h:
https://gerrit.asterisk.org/#/c/8390/1/include/asterisk/module.h@295
PS1, Line 295: AST_MODPRI_CORE = 40, /*!< A core module originally meant to start between preload and load. */
> Does this need it's own different priority value?
I don't think so, I'm not aware of any dependencies between timing modules and core modules.
If you'd like I can add 10 to AST_MODPRI_TIMING through AST_MODPRI_CDR_DRIVER so CORE modules will be loaded before timing and we'll still have 10 between each priority.
https://gerrit.asterisk.org/#/c/8390/1/main/Makefile
File main/Makefile:
https://gerrit.asterisk.org/#/c/8390/1/main/Makefile@21
PS1, Line 21: # Allow deletion of built-in modules without needing to modify this source.
> deletion?
As it is this supports deleting a couple core modules. For example it's possible to delete cel.c or enum.c, the build will continue without error. Deleting cel.c would mean that app_celgenuserevent and cel_* modules would be unable to load but Asterisk would still be able to load. Same for enum.c, only func_enum would be effected by deleting that built-in module.
Maybe this could be modified to use $(shell $(GREP) -e AST_MODULE_INFO -l), but then GREP would be mandatory (probably not an issue).
https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c
File main/asterisk.c:
https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c@4548
PS1, Line 4548: check_init(ast_cc_init(), "Call Completion Supplementary Services");
> Call completion reads the ccss.conf file so it needs to be a built in modul
Ah not sure how I missed this. Will fix in follow-up.
https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c@4550
PS1, Line 4550: /* We should avoid most config loads before this point as they can't use realtime. */
: check_init(load_modules(1), "Module Preload");
:
: /* Load remaining modules */
: check_init(load_modules(0), "Module");
> Is there any need for two module loads now? Or does this still need to be
It's still possible to force modules to higher in the load order by using 'preload'. I suspect we can eventually merge the two calls to load_modules so it builds a separate preload load priority list but that is not going to be part of this patch.
https://gerrit.asterisk.org/#/c/8390/1/main/cel.c
File main/cel.c:
https://gerrit.asterisk.org/#/c/8390/1/main/cel.c@1568
PS1, Line 1568: return AST_MODULE_LOAD_FAILURE;
> We should still be calling cel_engine_cleanup() i.e. unload_module() before
I think this is inconsistent. We do not run unload_module on 'core stop now', which is basically what is happening when we exit with failure. We definitely leak memory when we abort startup, if the next built-in module (after cel) fails to startup we never call the cel.c:unload_module, we just run things registered by ast_register_atexit and then terminate. Ultimately having a bunch of calls to unload_module for every error path doesn't really accomplish anything useful.
https://gerrit.asterisk.org/#/c/8390/1/main/dsp.c
File main/dsp.c:
https://gerrit.asterisk.org/#/c/8390/1/main/dsp.c@2407
PS1, Line 2407: int res = _dsp_init(0);
> We should return early if res is nonzero rather than possibly registering t
That makes sense, will do.
https://gerrit.asterisk.org/#/c/8390/1/main/features.c
File main/features.c:
https://gerrit.asterisk.org/#/c/8390/1/main/features.c@1168
PS1, Line 1168: return res ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_SUCCESS;
> We should be calling unload_module() if res is nonzero to cleanup on failur
See comments on cel.c.
https://gerrit.asterisk.org/#/c/8390/1/main/indications.c
File main/indications.c:
https://gerrit.asterisk.org/#/c/8390/1/main/indications.c@1141
PS1, Line 1141: return AST_MODULE_LOAD_FAILURE;
> We still should call indications_shutdown()/unload_module() here.
See cel.c.
https://gerrit.asterisk.org/#/c/8390/1/main/loader.c
File main/loader.c:
https://gerrit.asterisk.org/#/c/8390/1/main/loader.c@509
PS1, Line 509: mod = ast_calloc(1, sizeof(*mod) + strlen(info->name) + 1);
> This is going to get called before MALLOC_DEBUG/astmm.c has initialized for
Hmm I think I'll have to ast_std_calloc here, then when built-in modules are processed by modules_load I'll need to use ast_calloc to create a 'final' object and ast_std_free the one created here.
https://gerrit.asterisk.org/#/c/8390/1/res/res_config_sqlite.c
File res/res_config_sqlite.c:
https://gerrit.asterisk.org/#/c/8390/1/res/res_config_sqlite.c@1780
PS1, Line 1780: .requires = "cdr",
> Should it be extconfig?
This module is funny as it registers a realtime driver, loads config and registers a CDR backend.
Also looks like .support_level was missed, this module is deprecated.
--
To view, visit https://gerrit.asterisk.org/8390
To unsubscribe, visit https://gerrit.asterisk.org/settings
Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I371a9a45064f20026c492623ea8062d02a1ab97f
Gerrit-Change-Number: 8390
Gerrit-PatchSet: 1
Gerrit-Owner: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Thu, 08 Mar 2018 02:11:37 +0000
Gerrit-HasComments: Yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180307/b2fcf840/attachment.html>
More information about the asterisk-code-review
mailing list