Right now the drmem-config crate contains all the types for the .drmem.toml file. Because of this, it contains a mess of conditional compilation blocks to make sure the proper subset is defined.
Although it hasn't happened yet, it seems like someone could install the drmem-config crate with a different set of features than what drmemd uses. This might be more of an issue if/when we get drivers built and loaded as shared libraries.
The drmem-config crate should probably be removed.
Create a config module in drmemd which contains the base config definitions.
The backends will define their own definitions for the configuration they need.
The drmemd source will automatically get the correct configuration when it pulls in the appropriate backend.
Something like:
backend/db-redis-backend/src/config.rs
pub struct StoreConfig {
...
}
and in drmemd/src/core.rs
#[cfg(redis-backend)]
use db-redis-backend as store;
#[cfg(not(redis-backend))]
use db-simple-backend as store;
struct Config {
backend: store::StoreConfig,
}
Drivers use a TOML Map type for their configuration parameters. This definition should be moved to drmem-api::driver.
Right now the
drmem-config
crate contains all the types for the.drmem.toml
file. Because of this, it contains a mess of conditional compilation blocks to make sure the proper subset is defined.Although it hasn't happened yet, it seems like someone could install the
drmem-config
crate with a different set of features than whatdrmemd
uses. This might be more of an issue if/when we get drivers built and loaded as shared libraries.The
drmem-config
crate should probably be removed.config
module indrmemd
which contains the base config definitions.drmemd
source will automatically get the correct configuration when it pulls in the appropriate backend.Something like:
backend/db-redis-backend/src/config.rs
and in
drmemd/src/core.rs
Drivers use a TOML
Map
type for their configuration parameters. This definition should be moved todrmem-api::driver
.