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?