On Nov 13, 7:46pm, Masao Uebayashi wrote: } On Fri, Nov 13, 2015 at 8:05 PM, John Nemeth <jnem...@cue.bc.ca> wrote: } > On Nov 13, 6:34pm, Masao Uebayashi wrote: } > } 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. } > } > What does this have to do with xxx_modcmd()? It's also isn't } > necessarily a good enough reason to turn everything and its dog } > into a module. } > } > } > 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. } > } > That doesn't answer the concern that module init routines take } > a parameter and return a result code. If you yank the module init } > routine out of xxx_modcmd(), you remove significant functionality. } > } > } > 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. } > } > This is truely lame. It's not like you have to make a gazillion } > calls from init_main() to each module. One call to a module routine } > causes all modules to inited. } } Are you proposing to make everything a module and always use module } init routine?
I am most certainly not proposing to make everything a module. I started out in this thread by objecting to the idea that basic functionality should be modularised. } > Also, I don't think I've seen any discussion here. I've seen } > people asking you to tell us what your intentions are, without any } > kind of real response from you. } > } > } > } 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 } > }-- End of excerpt from Masao Uebayashi }-- End of excerpt from Masao Uebayashi