Pierangelo Masarati wrote:
that is, if both the database and the overlay allow back-config, there are cases in which config_set_vals() can be called with (arg_type & ARG_OFFSET) and the c->be points to the database's structure while c->bi points to the overlay's structure, and the config statement refers to the database although appearing after the overlay's instantiation.
This is Bad (TM) and should be avoided. However, for example, I have special needs in back-meta that require to allow overlay instantiation __before__ the database configuration is complete (in that case, I need an overlay to be instantiated before targets are defined, so that the overlay can get per-target configuration parameters much like the underlying database does). This may defer introduction of back-config support for back-meta.
Please disregard the above patch, which is incorrect as well. I think the right way to address the problem of selecting the right context for configure statements definitely consists in attaching into the ConfigTable a Conf->bi pointer to the BackendInfo that ConfigTable entry belongs to. This would allow to determine if the ConfigTable entry belongs to the underlying database, to an overlay, to the frontend or whatever, by comparing the BackendInfo* with that of the above stuff. Something like:
if ( c->be ) { if ( !overlay_is_over( c->be ) ) { ptr = c->be->be_private; } else if (((slap_overinfo *)c->be->bd_info)->oi_orig == Conf->bi ) { ptr = c->be->be_private; } }
if ( ptr == NULL && c->bi && c->bi->bi_type == Conf->bi->bi_type ) { ptr = c->bi->bi_private; } else { // error }
or whatever.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------