[Kamailio-Devel] [SR-Dev] extending module interface

[Andrei Pelinescu-Onciul]

On Nov 20, 2008 at 12:53, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> On 11/20/08 12:40, Andrei Pelinescu-Onciul wrote:
> >On Nov 20, 2008 at 11:50, Daniel-Constantin Mierla <miconda at gmail.com> 
> >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