libpathrs icon indicating copy to clipboard operation
libpathrs copied to clipboard

capi: add a configuration interface

Open cyphar opened this issue 5 years ago • 2 comments

The current pathrs_configure is designed after Linux's extensible syscall semantics. However, it seems to me that a string-based configuration setup would be far easier to extend naturally. Maybe the value should be an opaque pointer or some kind of typed-union struct, but having string keys would make extensibility so much simpler as well as lending itself very well to configuration files.

cyphar avatar Dec 30 '19 17:12 cyphar

My current idea looks something like:

pathrs_config_set(PATHRS_ROOT, root, "resolver.type", "emulated");
pathrs_config_set(PATHRS_NONE, NULL, "error.backtraces", true);

But the main problem is that you'd have to assume the type of the argument in this case (which is pretty annoying and might even be a bad idea with Rust's memory safety requirements). The alternative is something more like

pathrs_config_set(PATHRS_ROOT, root, "resolver.type", PATHRS_STRING, "emulated");
pathrs_config_set(PATHRS_NONE, NULL, "error.backtraces", PATHRS_BOOL, true);

Unfortunately that's just ugly. libconfig gives us a neat alternative:

pathrs_config_set_string(PATHRS_ROOT, root, "resolver.type", "emulated");
pathrs_config_set_boolean(PATHRS_NONE, NULL, "error.backtraces", true);

But then you run into the fun case of fetching the configuration values:

bool boolean;
char *str;
pathrs_config_get_boolean(PATHRS_NONE, NULL, "error.backtraces", &boolean);
pathrs_config_get_string(PATHRS_ROOT, root, "resolver.type", &str);
// how do we de-allocate str? do we need a pathrs_free(PATHRS_STRING, str)?

Anyway, I think the libconfig approach is the "nicest" one but we still need to figure out how the Rust API for configuration will work (which is an entirely separate problem -- see #24).

cyphar avatar Jan 25 '20 15:01 cyphar