On Nov 9, 8:05am, Paul Goyette wrote: } On Sun, 8 Nov 2015, Masao Uebayashi wrote: } } >> I don't see the point in having options for every single system call or } >> the like. At best, it is a form of modularity masturbation and at worst, } >> it is asking for difficult to analyze bugs when someone actually insists } >> on removing them. } > } > You need subsystem dependency information for decent initialization } > (a.k.a. kctors) ordering anyway. } > } > I also think that creating (practically useless) reduced kernel helps } > unit-testing. } } I'm not sure about helping unit testing, but it definitely helps to } keep the code organized. } } If any bugs do arise, they should be fixed, just like any other bugs. } One might argue that having this code as optional/removeable offers } new opportunities for finding bugs which affect other modules and/or } the loadable module mechanisms, and exposing and fixing these bugs } is beneficial to the project as a whole. } } So far, the only objections seem to be: } } * semaphores are pretty common, just about everyone will use } them, so there's no reason for them to be optional or } removeable } } * the semaphore code is fairly small, and having it as an } optional/removable module doesn't gain very much, and } isn't worth the effort. } } Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_ } optional. I would contend that EXEC_SCRIPT is much more widely used } than the semaphore code, and much more critical to operation of nearly } every NetBSD kernel, yet we still build them as optional/removable } modules. (And yes, I actually run my "production" machine with these } two modules - as well as AOI, MQUEUE, and EXEC_ELF64! - removed from } the baseline kernel; they all get auto-loaded as needed.) } } 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. } } So, unless there are strenuous objections, I'm planning to resurrect } the SEMAPHORE module in about a week.
You've had objections. It serves no purpose. }-- End of excerpt from Paul Goyette