Re: POSIX.1 semaphores vs message queues

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

I think that anything that is initialized after uvm_init() from
sys/kern/init_main.c:main() is worth being modularized, even if it
cannot be dynamically loaded.  Here, being modularized means that it
has a module name, it describes dependency on other modules, and has a
decent xxx_modcmd() entry (or better, kctors/kdtors).

On Mon, Nov 9, 2015 at 11:15 AM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Mon, Nov 9, 2015 at 9:21 AM, Joerg Sonnenberger
> <joerg%britannica.bec.de@localhost> wrote:
>> On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
>>> Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
>>> optional.
>>
>> See part about modularity masturbation. Making things optional for the
>> sake of making them optional is just as wrong.
>>
>>> Both EXEC_SCRIPT and COREDUMP are also much smaller than the ksem code;
>>> these two optional/removeable modules together add up to just about
>>> the size of a SEMAPHORE module.  (On amd64 we have exec_script weighing
>>> in at 1285 bytes and coredump at 3895 bytes, while ksem tips the scales
>>> at 5186 bytes).  There are numerous other modules which are similar in
>>> size to the SEMAPHORE module.
>>
>> Add in the page alignment and the cost becomes even larger. There is
>> nothing to be gained.
>
> Please don't (intentionally) confuse module in general and dynamic loading.
>
> For buiit-in modules, the extra size is code added by #ifdef _MODULE.
> In the long run, xxx_modcmd() functions are merged into kctors.  If
> other metada consume more than expected, it will be addressed and
> reconsidered.  But that goes away in !MODULAR kernels.  So virtually
> you lose nothing.