posticipate - realizing, while one writes a reply, that Yann has probably already implemented it.
X-) > Am 22.09.2017 um 14:48 schrieb Eric Covener <cove...@gmail.com>: > > Whoops I see you already folllowed it up. > > On Fri, Sep 22, 2017 at 8:46 AM, Eric Covener <cove...@gmail.com> wrote: >> On Fri, Sep 22, 2017 at 8:11 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >>> On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener <cove...@gmail.com> wrote: >>>> On Thu, Sep 21, 2017 at 8:44 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >>>>> On Thu, Sep 21, 2017 at 2:11 PM, Eric Covener <cove...@gmail.com> wrote: >>>>>> >>>>>> 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. >>>>> >>>>> Something like the attached patch might do it (untested, no MMN minor >>>>> bump). >>>>> >>>>>> >>>>>> (hopefully someone will check my work) >>>>> >>>>> Since modules (module_struct) are déclared globally, unspecified >>>>> fields at the end of the struct should be initialized to zero, so it >>>>> should be safe. >>>> >>>> I was thinking about modules compiled against the previous definition >>>> / out of tree. >>> >>> Hmm, I'm not sure my commits address this. >>> >>> The modules would be run by the latest core without being recompiled >>> against it, that's the case? >> >> Yes, I think it not yet handled because you're checking the cores MMN >> # at compile time. >> >> I think we need an accessor or macro to retrieve the flags that looks >> at the module_struct being evaluated which I think also has their >> compile-time MMN baked in. Probably best to have this be a simple >> function rather than a macro. >> >> >> -- >> Eric Covener >> cove...@gmail.com > > > > -- > Eric Covener > cove...@gmail.com
