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

[Andrei Pelinescu-Onciul]

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).


Andrei