I think that anything that is initialized after uvm_init() from sys/kern/init_main.c:main() is worth being modularized, even if it cannot be dynamically loaded. Here, being modularized means that it has a module name, it describes dependency on other modules, and has a decent xxx_modcmd() entry (or better, kctors/kdtors).
On Mon, Nov 9, 2015 at 11:15 AM, Masao Uebayashi <uebay...@gmail.com> wrote: > On Mon, Nov 9, 2015 at 9:21 AM, Joerg Sonnenberger > <jo...@britannica.bec.de> wrote: >> On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote: >>> Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_ >>> optional. >> >> See part about modularity masturbation. Making things optional for the >> sake of making them optional is just as wrong. >> >>> Both EXEC_SCRIPT and COREDUMP are also much smaller than the ksem code; >>> these two optional/removeable modules together add up to just about >>> the size of a SEMAPHORE module. (On amd64 we have exec_script weighing >>> in at 1285 bytes and coredump at 3895 bytes, while ksem tips the scales >>> at 5186 bytes). There are numerous other modules which are similar in >>> size to the SEMAPHORE module. >> >> Add in the page alignment and the cost becomes even larger. There is >> nothing to be gained. > > Please don't (intentionally) confuse module in general and dynamic loading. > > For buiit-in modules, the extra size is code added by #ifdef _MODULE. > In the long run, xxx_modcmd() functions are merged into kctors. If > other metada consume more than expected, it will be addressed and > reconsidered. But that goes away in !MODULAR kernels. So virtually > you lose nothing.
