https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/include/modules.h?h=amdj%2Fautotools-version-fix 2026-03-22T00:10:35Z 2026-03-22T00:10:35Z Aaron Jones 2026-03-11T03:57:11Z urn:sha1:232c2c13c64f3b1373eef16645b90bdb3233210d The existing code had several defects: - Core module file names were hardcoded, while autoloaded non- core module filenames were not. Code that loaded core modules had a different but in some places duplicated structure to the code that loaded autoloaded modules. - Module loading for autoloaded modules happened in dentry order, making it unpredictable from one server to the next, or even across instances of `make install` on the same server. - Module loading for autoloaded modules did not verify that the dentry was a file before trying to load it. - An IRCd start (or a conftest) only printed lines about loading modules mentioned in the configuration file. - The configuration file was parsed before loading core and autoloaded modules, meaning any modules specified in the configuration file would be loaded first. - Once a module was loaded, it was added to the head of the module list, making MODLIST show them in reverse loaded order (newest (re)loaded modules at the top of the list). These are addressed as follows: - We now scan the core and autoload module directories and use this to determine which modules to load. - We now sort the dentries according to their filename before iterating them to load them, making module load order finally deterministic. - We now test if a dentry is actually a file before trying to load it. - We now print a message to the console (if running in foreground or conftest mode) when loading any module, including core and autoloaded modules. - The message printed to the console now has the IRCd module directory prefix stripped from it if it matches. - The configuration file is now parsed after loading core and autoload modules. - The modules are added to the module list in the order that they are loaded. This now makes MODLIST show the order that modules were (re)loaded in. Modifications to two modules are part of this effort: - The autoload module `m_alias` relied upon the alias dict not being NULL when loaded, but this is only the case after the configuration file has been parsed. The module already had a "rehash" hook to destroy all existing aliases and create new ones, so we can just make the module do nothing on load (remove its modinit function) and change it to use the "conf_read_end" hook instead of the "rehash" hook, and it will still create aliases after the configuration file is subsequently parsed. With this modification, there are now no in-tree consumers of the "rehash" hook. - The autoload module `m_services` iterated `service_list` upon loading it, which will now be empty (a no-op) since the module is loaded before configuration file is parsed. This module too handles the configuration file being parsed with a "conf_read_end" hook and takes the appropriate action, so we can just remove this code from its modinit function. All other modules' modinit functions have been audited for behaviour like this; there was nothing of note. 2026-03-17T20:22:38Z Ryan Schmidt 2026-03-15T23:28:55Z urn:sha1:3253a979e4d9230fbad9a1fb9e6fc8a81aebc4ce The previous commit addressed the issue with (most) function signatures, but forgot to update the caps themselves to be 64-bit. This fixes that, and finishes the remaining overlooked function signatures. 2020-10-15T14:52:41Z Ed Kellett 2020-10-15T14:51:12Z urn:sha1:a6f63a829e22fa83a4551cb9aad3e316e7c8bb18 2020-06-25T17:32:58Z Aaron Jones 2020-06-25T17:32:58Z urn:sha1:17dc265c9d6fa4e88b25bdbf89a35020d039c52c Reload modules by path 2020-06-02T15:17:26Z Ed Kellett 2020-06-02T15:17:26Z urn:sha1:df7e3dabce92bfa83d59e93cb8cf112e632a757b 2020-05-01T16:44:15Z Ed Kellett 2020-04-26T23:14:56Z urn:sha1:91b1278224692433c4ec42ee04e06cf64373dde3 2019-11-17T18:01:51Z Ed Kellett 2019-11-17T11:15:47Z urn:sha1:7b6410135b2bf53efcdf7ecb9f073f73f5d84918 /modrestart used to be implemented as a normal command and could crash when used remotely because it would reload m_encap, which was on the call stack at the time. This was fixed in 41390bfe5f. However, /modreload has exactly the same problem, so I'm giving it the same treatment. Incidentally: This bug was first discovered in ircd-seven, where the `/mod*` commands themselves live in the core, so m_encap was the only way the crash could happen (and it didn't most of the time, because m_encap would only be moved if you got unlucky). But `/mod*` are in modules in charybdis, so /modrestart would have unloaded the code it was in the middle of executing. With that in mind, I'm not sure how it ever appeared to work. 2019-09-07T13:59:33Z Ed Kellett 2019-07-08T02:53:29Z urn:sha1:28cc8bb9241eca95f432ff41c78ce14ae9ac7905 Reloading modules sends CAP DEL followed by an immediate CAP NEW: :staberinde.local CAP * DEL :account-tag :staberinde.local CAP * NEW :account-tag This isn't very nice. /modrestart is particularly bad. In order to avoid doing this, we remember the capability set at the beginning of module operations, compare that with the set afterwards, and report only the differences with CAP {DEL,NEW}. 2016-06-18T05:52:16Z William Pitcock 2016-06-18T05:52:16Z urn:sha1:e55a9d6abc68a467ec5b6fef51d9c71608035329 2016-06-18T05:38:40Z William Pitcock 2016-06-18T05:38:40Z urn:sha1:92dad4831d323af85d2c0084191e7b33b0149273