<p>Corey Farrell <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/8390">View Change</a></p><p>Patch set 1:</p><p style="white-space: pre-wrap; word-wrap: break-word;">I should be able to get an updated posted in the next couple days.</p><p>(10 comments)</p><ul style="list-style: none; padding-left: 20px;"><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/include/asterisk/module.h">File include/asterisk/module.h:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/include/asterisk/module.h@295">Patch Set #1, Line 295:</a> <code style="font-family:monospace,monospace"> AST_MODPRI_CORE = 40, /*!< A core module originally meant to start between preload and load. */</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Does this need it's own different priority value?</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">I don't think so, I'm not aware of any dependencies between timing modules and core modules.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/Makefile">File main/Makefile:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/Makefile@21">Patch Set #1, Line 21:</a> <code style="font-family:monospace,monospace"># Allow deletion of built-in modules without needing to modify this source.</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">deletion?</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Maybe this could be modified to use $(shell $(GREP) -e AST_MODULE_INFO -l), but then GREP would be mandatory (probably not an issue).</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c">File main/asterisk.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c@4548">Patch Set #1, Line 4548:</a> <code style="font-family:monospace,monospace"> check_init(ast_cc_init(), "Call Completion Supplementary Services");</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Call completion reads the ccss.conf file so it needs to be a built in modul</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">Ah not sure how I missed this. Will fix in follow-up.</p></li><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/asterisk.c@4550">Patch Set #1, Line 4550:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;"> /* We should avoid most config loads before this point as they can't use realtime. */<br> check_init(load_modules(1), "Module Preload");<br><br> /* Load remaining modules */<br> check_init(load_modules(0), "Module");<br></pre></blockquote></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Is there any need for two module loads now? Or does this still need to be </blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/cel.c">File main/cel.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/cel.c@1568">Patch Set #1, Line 1568:</a> <code style="font-family:monospace,monospace"> return AST_MODULE_LOAD_FAILURE;</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">We should still be calling cel_engine_cleanup() i.e. unload_module() before</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/dsp.c">File main/dsp.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/dsp.c@2407">Patch Set #1, Line 2407:</a> <code style="font-family:monospace,monospace"> int res = _dsp_init(0);</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">We should return early if res is nonzero rather than possibly registering t</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">That makes sense, will do.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/features.c">File main/features.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/features.c@1168">Patch Set #1, Line 1168:</a> <code style="font-family:monospace,monospace"> return res ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_SUCCESS;</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">We should be calling unload_module() if res is nonzero to cleanup on failur</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">See comments on cel.c.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/indications.c">File main/indications.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/indications.c@1141">Patch Set #1, Line 1141:</a> <code style="font-family:monospace,monospace"> return AST_MODULE_LOAD_FAILURE;</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">We still should call indications_shutdown()/unload_module() here.</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">See cel.c.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/main/loader.c">File main/loader.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/main/loader.c@509">Patch Set #1, Line 509:</a> <code style="font-family:monospace,monospace"> mod = ast_calloc(1, sizeof(*mod) + strlen(info->name) + 1);</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">This is going to get called before MALLOC_DEBUG/astmm.c has initialized for</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li></ul></li><li><p><a href="https://gerrit.asterisk.org/#/c/8390/1/res/res_config_sqlite.c">File res/res_config_sqlite.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/8390/1/res/res_config_sqlite.c@1780">Patch Set #1, Line 1780:</a> <code style="font-family:monospace,monospace"> .requires = "cdr",</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Should it be extconfig?</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">This module is funny as it registers a realtime driver, loads config and registers a CDR backend.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Also looks like .support_level was missed, this module is deprecated.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/8390">change 8390</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/8390"/><meta itemprop="name" content="View Change"/></div></div>
<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I371a9a45064f20026c492623ea8062d02a1ab97f </div>
<div style="display:none"> Gerrit-Change-Number: 8390 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 08 Mar 2018 02:11:37 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>