[sr-dev] Question about config framework (ser)

[Miklos Tirpak]

Hi Henning,

On 02/17/2010 11:22 AM, Henning Westerholt wrote:
> On Wednesday 17 February 2010, Miklos Tirpak wrote:
>> [..]
>> 2) Some modules update local or even shared memory variables based on
>> cfg variable changes. It would be nice to solve as many cases within the
>> framework as possible. For example the modules could have write access
>> to their variables during fixup, or more complicated structures could be
>> stored not only int and str vars. If you miss any feature therefore you
>> keep variables outside of the framework then please speak up!
> 
> Hi Miklos,
> 
> indeed this is another problem which we've also discussed during the planning 
> for the cfg framework migration work, its present for example in the ratelimit 
> and carrierroute modules. 
> 
> Quite a few kamailio modules implemented also their own version of reload 
> functionality with a FIFO command, e.g. "reload_fifo" in 
> modules/carrierroute/cr_fifo.c. This is more or less a similar use case like 
> the cfg framework represents (atomic reload of a variable), but with a a bit 
> more complicated data structure (route_data_t).
> 
> So having a generic version for this in the cfg framework would be indeed nice 
> in my opinion.

the route_data_t structure seems to be the routing data similar to what 
a route block does in the script, I mean that it is not like a modparam. 
This is a bit far from the initial concept of the cfg framework but this 
would not be a problem.

In the framework, there are module and core parameters declared by the 
modules/core and there are cfg drivers that write the parameters. They 
can work on any backend, file, DB, srcmd... Hence, the drivers or the 
framework must know the structure of the configuration, i.e. what type 
of value is stored in which slot. The route_data_t structure is quite 
complex, the number of carriers and the number of domains is not known 
in advance, therefore the size of the structure is also unknown. The 
framework could hardly tell what is stored on a given memory address. 
The best we could do is to let the carrierroute module write its own 
configuration and do not touch it by other modules, I mean by the cfg 
drivers.

Actually the framework already supports the void* type that could be 
used for this purpose (with some enhancements). The module could load 
the config, allocate the necessary space in shm mem, and link it to the 
global configuration via the void* pointer. From this point the 
framework could offer:

- consistency: The config would remain the same during a SIP message 
processing. Even if there is a new config available, it would be used 
only for the next message routeing.

- locking: The carrierroute module should not care about locking the 
data structures during reading because it is the task of the framework. 
In fact, the framework supports lockless read because all modifications 
(except with the atomic flag) copy the entire config block first and 
modify the clone. This is done for performance reasons because the 
assumption is that the config rarely changes but it is read many times.
This means that even the carrierroute module is not allowed to simply 
write its data structures. It should always construct a new structure 
(or clone the existing one) and link the new configuration to the global 
cfg structure via some interface.

So I do not see to much benefit of using the cfg framework in this case 
because the structure that needs to be stored does not have a fixed 
size, therefore it is hard to specify for the framework. In this case 
the carrierroute module would be the only one that can read/write the 
config which is nothing different from the current situation.
Or do you think that the consistency and locking are worth the effort?

Regards,
Miklos

> 
> Cheers,
> 
> Henning