On Thu, Sep 21, 2017 at 7:42 AM, Stefan Eissing <[email protected]> wrote: > >> Am 21.09.2017 um 13:35 schrieb Eric Covener <[email protected]>: >> >> On Thu, Sep 21, 2017 at 7:00 AM, Yann Ylavic <[email protected]> wrote: >>> On Thu, Sep 21, 2017 at 11:48 AM, Stefan Eissing >>> <[email protected]> wrote: >>>> >>>>> Am 21.09.2017 um 11:37 schrieb Yann Ylavic <[email protected]>: >>>>> >>>>> 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 [email protected]
