gssapi, ldap and lua modules may be initialized specially via auth/passdb.c (passdbs_init).

This is approximately correct (to be precise, gssapi is done in auth/mech.c (mech_init)). What this means is that those modules (libauthdb_ldap, libauthdb_lua and libmech_gssapi) are already set up to work builtin, much like libdict_ldap in #4. Thus I'm thinking they can be left in. This leaves libauthdb_imap, which is built unconditionally and has no builtin variant, so I might go ahead and remove it along with the load point; it looks fairly self-contained so this should be easy. Then again, it could still be sustained using the new static module structure.

Re #9,

It would seem that auth modules can add functionality both to the "auth" daemon process (handling authentication requests) and to doveadm (perhaps configuring users & passwords).

Nonetheless I can't find how doveadm would be at all affected by auth modules, at least the authdb and mech ones on the table. Thus I'd go ahead and remove the load point but leave the auth modules alone except as covered in #2.

5, 7 and 13 are threatening to turn into further time sinks. Besides that, the removals are going smoothly enough.

There's another load point at auth_module_load, called by passdb_preinit, userdb_preinit and mech_register_init, which seems entirely redundant with this one, loading specific modules that would be already covered by the blanket loading here.

what's up there is that the blanket load point is using a filter function passed through a settings struct to exclude any module names starting with authdb_ or mech_ (that is, all of the listed non-plugin modules), stating that those are "lazily loaded" i.e. by the mentioned auth_module_load.

I'd say then that the case is even clearer for removing the blanket load point which in fact covers only the var-expand-crypt plugin, while gssapi/ldap/imap auth options could perhaps still be kept with minimal extra effort given the way things are shaping up anyway.

Can one module extend both mail (imap etc) and lmtp processes, or are these properly regarded as distinct module types?

doc/example-config/conf.d/20-lmtp.conf illustrates a mail_plugins setting within a "protocol lmtp" block, describing it as a "space separated list of plugins to load (default is global mail_plugins)." This strongly suggests that they're the same type of module, just that you can load different ones for the different protocols.

The approach will likely be a hybrid, enumerating the specific modules at the load points as proposed, thereby getting them linked into the necessary binaries, perhaps using a MODULE_LOAD_STATIC macro of some sort to specify the name and init/deinit routines, or a virtual method table structure to define them within each module itself. Then the remaining module object methods would continue to be used as-is.

Yet another complication (undocumented) is that a module can also have a "preinit" routine which if present is called at load time. The old-stats plugin (lib90_old_stats_plugin) has the only instance of it among the plugins; unsure about non-plugin modules so far. Its use there is to open /proc/self/io, for later gathering counts of read/write syscalls and total bytes. I hadn't encountered this interface before so looked it up in proc(5), which reports its origin as Linux kernel 2.6.20 and notes:

In the current implementation, things are a bit racy on 32-bit systems: if process A reads process B's /proc/[pid]/io while process B is updating one of these 64-bit counters, process A could see an intermediate result.

IOW, it can sometimes report nonsense values. Needless to say, I'm unimpressed and would sooner take it out (which looks quite simple) than implement the preinit mechanism just for this.

However, I do not think it would be accurate to classify them as either Authentication or Dictionary modules, because they do not by themselves implement any new auth method or dict backend. Rather, they implement an internal SQL API (as in lib-sql/sql-api.c et al, with its own virtual method dispatch table and all) which is used in turn by the builtin auth/db-sql.c on the auth side and ...apparently nothing on the dict side.

Thus, despite lacking a load point of their own I think it's fair to consider them a distinct module type: SQL Driver, and I stand by the proposed action: "like #4, to remove the plugin option so they're either builtin or absent".

The bleeding stanched from this hole in my model, I now believe the non-plugin modules have been fully listed, on the strength of a "grep 'module_.*LTLIBRARIES' -r src" not turning up anything new outside of plugins. I will update the article to strike out those cautiously listed as "unknown".

I don't think the removals will generally come up as hard necessities; it's more that the code becomes dead weight, slowing down any codebase-wide operations like searching (and compiling, though at least that's just a matter of machine time), as well as local operations like reading. A compromise would be to remove just the condemned plugins/modules as proposed but leaving the load points, since it would be mostly a file or directory level removal, rather than removing code within a file and possibly cascading up to the callers.

I guess your argument is basically, we did the hard part of finding what can be safely killed and setting it all down, but so far it's not even worth the expenditure of ammunition to follow through. I'll demur on expressing an inclination for now, but can certainly start with the required parts like answering the SQL drivers question and taking the actions for 8, 10 and 14.