Tanay Abhra <tanayabh@xxxxxxxxx> writes: > What changes should I implement in this series? Should I add new > user facing API adding to the singleton callers which are already in > this series. I think the underlying data structures that represent what the entire set of config data is needs to be refined. We did this kind of conversion once, back when we made it possible to handle more than one instances of in-core cache. You may want to study the series that implemented the transition to learn ideas from. - We used to have a single "struct cache_entry **cache", a single pair of "unsigned int cache_nr, cache_alloc", etc. and the first patch to introduce the feature was to define "struct index_state" that holds all of these "what the entire set of data that represent the status of the in-core cache is" variables. - We also used to have a set of functions that work on the singleton instance of the in-core cache (read_cache(), write_cache(), etc.). We introduced a new set of API functions to take an explicit pointer to the "struct index_state" we want to work on, and made these old "assume the singleton" functions a set of thin wrappers that pass &the_index to the corresponding new API functions. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html