Re: POSIX.1 semaphores vs message queues

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 13,  7:46pm, Masao Uebayashi wrote:
} On Fri, Nov 13, 2015 at 8:05 PM, John Nemeth <jnemeth%cue.bc.ca@localhost> wrote:
} > On Nov 13,  6:34pm, Masao Uebayashi wrote:
} > } 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.
} >
} >      What does this have to do with xxx_modcmd()?  It's also isn't
} > necessarily a good enough reason to turn everything and its dog
} > into a module.
} >
} > } > 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.
} >
} >      That doesn't answer the concern that module init routines take
} > a parameter and return a result code.  If you yank the module init
} > routine out of xxx_modcmd(), you remove significant functionality.
} >
} > } > 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.
} >
} >      This is truely lame.  It's not like you have to make a gazillion
} > calls from init_main() to each module.  One call to a module routine
} > causes all modules to inited.
} 
} Are you proposing to make everything a module and always use module
} init routine?

     I am most certainly not proposing to make everything a module.
I started out in this thread by objecting to the idea that basic
functionality should be modularised.

} >      Also, I don't think I've seen any discussion here.  I've seen
} > people asking you to tell us what your intentions are, without any
} > kind of real response from you.
} >
} > } > } 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
} > }-- End of excerpt from Masao Uebayashi
}-- End of excerpt from Masao Uebayashi