tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: POSIX.1 semaphores vs message queues
On Mon, Nov 9, 2015 at 7:13 PM, John Nemeth <jnemeth%cue.bc.ca@localhost> wrote:
> On Nov 9, 11:15am, Masao Uebayashi 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
>
> Uh, I don't think so. Not unless you have one heck of a good
> reason.
If you need only one reason: dynamically loadable modules help
development and debugging.
> xxx_modcmd() does more then just initialize the module.
I know I know... That sentence should have been read as: *part of*
xxx_modcmd() *might be* merged into kctors.
> Spreading that stuff all over the place would not be nice. Also,
> we need to be able to pass parameters to the initialization routine
> and check the return code. These are NOT fire and forget routines.
>
> There is a reason that planned major changes are supposed to
> be discussed. It is so that people know what is happening and to
> give people a chance to point out things you might not have thought
> of. "By the way, this is what's going to happen," is not how you
> start a discussion.
I have tried to explain the need of kctors, instead of hardcoded
sequence of xxx_init() functions in init_main.c:main(), generated by
dependency.
> } other metada consume more than expected, it will be addressed and
> } reconsidered. But that goes away in !MODULAR kernels. So virtually
> } you lose nothing.
> }-- End of excerpt from Masao Uebayashi
Home |
Main Index |
Thread Index |
Old Index