On Nov 20, 2008 at 12:53, Daniel-Constantin Mierla <[EMAIL PROTECTED]> wrote: > > > On 11/20/08 12:40, Andrei Pelinescu-Onciul wrote: > >On Nov 20, 2008 at 11:50, Daniel-Constantin Mierla <[EMAIL PROTECTED]> > >wrote: > > > >>Hello, > >> > >>working to port PV engine to srouter, but also needed for kamailio's > >>migration of pseudo-variables (PVs) from core to modules, I need to > >>extend the module interface. The srouter has already support to work in > >>dual mode committed by Andrei few days ago, so it should affect only > >>kamailio's module interface if ser side does not need. > >> > >>Here is the issue. In kamailio/openser we have so called transformations > >>that are bound to PV. They are now implemented directly in core. To move > >>them in a module, the interface needs to be extended, like we did in the > >>past to export PVs from modules. > >>The important aspect is that they must > >>become visible immediately after the module is loaded -- this happens > >>also with PVs (so cannot use mod_init, etc...). This is required because > >>they may occur during script parsing, therefore the core/parser should > >>get knowledge of them in very early stage. > >> > >>PVs are exported via a specific structure in module interface. We can do > >>same for transformations. There is another option, which can be used for > >>other purposes in the future - introducing in module interface a > >>callback to be run immediately after a module is loaded. The > >>transformations can be exported inside the callback. > >> > > > >I personally don't like extending the module_export structure. It was > >done a lot in the past (both in kamailio/openser and ser), but IMHO > > is a mistake, because then you have to update _all_ the module to the > > new interface or do some hack like we have in sip-router to support > > several module interface versions. > >Instead of extending the structure is better to either add a new one > > an look (dlsym) for it when loading a module (if it's not present we > > just assume the module doesn't implement it), or use a callback. > > > > > >>Extending this way, in the future, the modules can make other attributes > >>visible to core/other modules immediately after loading without changing > >>the module interface. > >> > >>Therefore I would go for second option. Other opinions? > >> > > > >I prefer the callback too. As a matter of fact the first ser versions > >used to have a mod_register function for exactly that purpose: > >the module loader would resolve the mod_register symbol (dlsym()) and > >then call it. In the first versions mod_register would also add/register > >the module_export structure (which was not automatically loaded). > > > >I was going to propose mod_register revival too, for slightly different > >reasons: > > - IMHO the mod_export structure is too big and some parts of it are > > used only by a few modules, so I think it's easier/nicer to keep it > > smaller and register the not so common stuff from mod_register. > > - using this callback mechanism is easy to extend mod_export in the > > future without requiring _any_ change in modules who don't implement / > > don't > > care for the new functionality. > > - on some system it seems not to be possible to resolve a symbol pointing > > to a data structure, only symbols pointing to functions are ok (that > > and windows are on of the reasons for the static modules compilation > > options). So if we ever decide to fully support such systems we might > > need to register everything from mod_register even the module_export > > structure (we could make some macro that would do this > > semi-automatically). > > - one could dynamically manipulate mod_exports, before it's register > > (e.g. change pointer to functions depending on whether or not the > > system is smp :-)). > > > > > >So as first step I would add support for looking for and executing > > mod_register when loading the modules, before resolving/registering > > mod_export. The prototype for it would look like: > > int mod_register(char* path, int* dlflags) > > (it's better to do the dlflags hack as soon as possible) > > ret < 0 => don't load the module, 0 success, >0 reserved for future use. > > > >Does anybody disagree? > >Do you have a better name, or better prototype proposal? > > > >No _quick_ answer will be considered agreement (we can easily change it > >latter anyway if only a few module use it). > > > mod_register sounds good. > > I was looking to keep everything in module_exports structure, just for > consistency. But this indeed requires a lot of updates upon small change > there. > > As you say, from perspective of portability, exporting by function is > better. > > What would be the meaning of path parameter in mod_register? The module > name?
The path including the module name (what was passed to dlopen). It might be usefull in some corner cases (like module who wants to load another module/plugin). Andrei _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
