Re: POSIX.1 semaphores vs message queues

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Sun, Nov 8, 2015 at 7:52 AM, Joerg Sonnenberger
<joerg%britannica.bec.de@localhost> 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.