On Sat, 7 Nov 2015, John Nemeth wrote:
On Nov 8, 7:22am, Paul Goyette wrote: } 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....In general, I like the idea of modules. However, in this case, I pretty much agree with Joerg and have to ask, what is the point of modularising basic functionality? Is having it in the kernal all the time causing some kind of issue?
No, having it in the kernel all the time isn't causing any issues, at least none of which I'm aware. My inquiry really comes down to this: There are other areas of "basic functionality" which are modular (although some might be "more basic" than others) so why should ksem be any different? As another example (beyond MQUEUE and AIO), we allow the user to remove all of the SECMODEL options, which to me seems like a _much_ more basic functionality than ksem. +------------------+--------------------------+-------------------------+ | 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 | +------------------+--------------------------+-------------------------+
