On Thu, Sep 21, 2017 at 7:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 21.09.2017 um 13:35 schrieb Eric Covener <cove...@gmail.com>: >> >> On Thu, Sep 21, 2017 at 7:00 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >>> On Thu, Sep 21, 2017 at 11:48 AM, Stefan Eissing >>> <stefan.eiss...@greenbytes.de> wrote: >>>> >>>>> Am 21.09.2017 um 11:37 schrieb Yann Ylavic <ylavic....@gmail.com>: >>>>> >>>>> If the module defines its own server_config_create() which allocates >>>>> one, each vhost will have its own, and the module's >>>>> server_config_merge() can do whatever needs to for the members of the >>>>> config (pointer copy, shallow/deep copy, ...). >>>> >>>> Yes, but only *iff* there is every a directive of that module used in >>>> a VirtualHost. >>> >>> OK, I see know, thanks. >>> >>> I'd call that a premature optimization though, even if it matured for >>> decades :) >>> Only the module knows what to do when merging, so I think the core >>> config should still call config_create() and config_merge() for those, >>> precisely because post_config() is always called. >>> Modules also know how to merge configs that do nothing (usually), with >>> all those _set members all over the place, so it should work (untested >>> ;) even if it may consume more (not that much I think) initial memory >>> for large confs. >> >> Maybe less intrusive for a module to make a copy of its config if it >> detects base/vh are the same and needs them to differ? > > That is why I "fixed" this for mod_ssl only. But mod_md has similar code now. > > Do we have some sort of bitfield of flags for each module? That would be great > as we could make an opt-in change that way. >
IIUC it should be safe to extend module_struct with a minor bump to add 'int flags' to the bottom, but when you check the value you'd need to check the MMN first. In the module you'd then just have some flags or'ed together after register_hooks. (hopefully someone will check my work) -- Eric Covener cove...@gmail.com
