Tanay Abhra <tanay...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html