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

[Henning Westerholt]

On Monday 22 February 2010, Miklos Tirpak wrote:
> > [..]
> > So having a generic version for this in the cfg framework would be indeed
> > nice in my opinion.

Hello Miklos,

thanks for the reply.

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

Yes, its indeed a more complicated data structure.

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

Yes, this is true. It would probably not make too much sense to let other 
modules tinker in this informations, a generic reload function would be more 
meaningful in this case.

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

Ok, i understand. This is more or less the same way the module works at the 
moment.

> 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?

Good question. In cr we handle it in a way that even the module does not write 
into this datastructure, and there is only one place which updates it under a 
lock. (Writing to the route data during runtime would be a problem for the 
performance as the datastructure is somewhat bigger.) So if its not really fit 
into the (existing) framework and we don't really benefit from the added 
consistency at the moment, the only real reason to use a central functionality 
would be to have a unified interface for reloads across several modules.

Regards,

Henning