On Sun, Nov 8, 2015 at 7:52 AM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > On Sun, Nov 08, 2015 at 06:35:36AM +0800, Paul Goyette wrote: >> On Sat, 7 Nov 2015, Joerg Sonnenberger wrote: >> >> >On Sat, Nov 07, 2015 at 10:55:49AM +0800, Paul Goyette wrote: >> >>I'd like to understand the rationale that makes POSIX sempahores a >> >>non-optional component of the kernel, while POSIX message queues are >> >>still optional. Both seem to be related specifically to use in the >> >>librt real-time library. >> > >> >Semaphores are used quite a lot and not only required by librt, but >> >also by libpthread. I'm not sure what is using message queues. >> >> Hmmm, sounds like a great reason to include the semaphore code in >> every kernel by default. But it doesn't sound sufficiently critical >> to _prevent_ it from being removed from custom kernels if explicitly >> requested by the user. >> >> I'd like to suggest that this code once again become an option. Rather >> than adding an option to every kernel configuration file, however, we >> can simply add it to src/sys/conf/std where it will get included by >> default, in the same manner as MQUEUE. (I also propose use of "option >> SEMAPHORE" rather than P1003_1B_SEMAPHORE, similar to MQUEUE.) > > 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.
