Re: [SR-Dev] extending module interface

On Nov 20, 2008 at 11:50, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; 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).