Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

capi: add a configuration interface #21

Open
cyphar opened this issue Dec 30, 2019 · 2 comments
Open

capi: add a configuration interface #21

cyphar opened this issue Dec 30, 2019 · 2 comments
Labels
api/cffi Related to the C-FFI API. help wanted Extra attention is needed ideas welcome An open problem which doesn't have a clear resolution.
Milestone

Comments

@cyphar
Copy link
Member

cyphar commented Dec 30, 2019

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 cyphar added help wanted Extra attention is needed ideas welcome An open problem which doesn't have a clear resolution. api/cffi Related to the C-FFI API. labels Dec 30, 2019
@cyphar
Copy link
Member Author

cyphar commented Jan 25, 2020

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 cyphar added this to the 0.1.0 milestone Sep 11, 2024
@cyphar
Copy link
Member Author

cyphar commented Sep 11, 2024

Now that we redesigned the API in #34, the config API probably will need to look like:

pathrs_config_t *conf = pathrs_config_new();
if ((liberr = pathrs_config_set_bool(conf, "errors.simple_errno", true)) < 0)
	goto err;
if ((liberr = pathrs_config_set_string(conf, "root.resolver", "opath")) < 0)
	goto err;

pathrs_resolve(rootfd, "foo"); // no config
pathrs_resolve_c(conf, rootfd, "foo"); // with the config
pathrs_config_free(conf);

While all of the stuff we'd want would work as bitflags at the moment, I'm a little worried about future extensibility.

@cyphar cyphar modified the milestones: 0.1.0, 0.2.0 Sep 11, 2024
@cyphar cyphar changed the title alternative pathrs_configure capi: add a configuration interface Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api/cffi Related to the C-FFI API. help wanted Extra attention is needed ideas welcome An open problem which doesn't have a clear resolution.
Projects
None yet
Development

No branches or pull requests

1 participant