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? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
