On Mon, Nov 9, 2015 at 7:13 PM, John Nemeth <jnem...@cue.bc.ca> wrote: > On Nov 9, 11:15am, Masao Uebayashi 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 > > Uh, I don't think so. Not unless you have one heck of a good > reason.
If you need only one reason: dynamically loadable modules help development and debugging. > xxx_modcmd() does more then just initialize the module. I know I know... That sentence should have been read as: *part of* xxx_modcmd() *might be* merged into kctors. > Spreading that stuff all over the place would not be nice. Also, > we need to be able to pass parameters to the initialization routine > and check the return code. These are NOT fire and forget routines. > > There is a reason that planned major changes are supposed to > be discussed. It is so that people know what is happening and to > give people a chance to point out things you might not have thought > of. "By the way, this is what's going to happen," is not how you > start a discussion. I have tried to explain the need of kctors, instead of hardcoded sequence of xxx_init() functions in init_main.c:main(), generated by dependency. > } other metada consume more than expected, it will be addressed and > } reconsidered. But that goes away in !MODULAR kernels. So virtually > } you lose nothing. > }-- End of excerpt from Masao Uebayashi