On Sat, 7 Nov 2015, Joerg Sonnenberger 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.
I do understand your position. And I'm well aware of how difficult it can be to analyze any bugs that get introduced. (Refer my recent issues that resulted from fixing the module dependencies for compat_netbsd32, or the issue with SYSVSEM, which took a couple of weeks to locate and fix.) This isn't a request to modularize a single syscall, it's a complete set of ten syscalls for a self-contained set of functionality on which there are no other kernel or modular dependencies. There is no functional impact on anyone who uses standard kernels. I only impacts those who explicitly request the exclusion of this code from their kernels, and in the exact same manner as requesting the exclusion of MQUEUE or AIO. (And yes, I run with both of those removed from my kernels, loading the modules on-demand.) Based on the (lack of) commentary I received in my recent bug-hunts, it seems that very few people would care about re-modularizing ksem. I'm willing to do all the work (actually, it's already done, except for testing and fixing any bugs I find). I'd really appreciate comments from others.... +------------------+--------------------------+-------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+-------------------------+