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

Config subsys #1488

Closed
wants to merge 18 commits into from
Closed

Config subsys #1488

wants to merge 18 commits into from

Conversation

nmathewson
Copy link
Contributor

No description provided.

This will help us reimplement warn_about_relative_paths().

FILENAME options currently are the same as STRINGs in most respects,
except for the type reported to the controller.

In this commit, I'm picking the options to change based on:
  * the current contents of warn_about_relative_paths()
  * options that end with "File".
@coveralls
Copy link

coveralls commented Oct 30, 2019

Pull Request Test Coverage Report for Build 7038

  • 112 of 135 (82.96%) changed or added relevant lines in 6 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.009%) to 62.14%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/app/config/statefile.c 4 5 80.0%
src/lib/crypt_ops/crypto_init.c 18 20 90.0%
src/app/main/subsysmgr.c 58 78 74.36%
Totals Coverage Status
Change from base Build 7037: 0.009%
Covered Lines: 48392
Relevant Lines: 77876

💛 - Coveralls

This file is a workaround for the issue that if you say `a ## b` to
create a token that is the name of a macro, the C preprocessor won't
expand that macro.  So you can't say this:

#define FOO__SQUARE(x) ((x)*(x))
#define FOO__CUBE(x)   ((x)*(x)*(x))
#define FOO(func, x)   FOO__##func(x)

Instead, the standard C trick is to add a layer of indirection:

#define PASTE(a,b)     PASTE__(a,b)
#define PASTE__(a,b)   a ## b

#define FOO__SQUARE(x) ((x)*(x))
#define FOO__CUBE(x)   ((x)*(x)*(x))
#define FOO(func, x)   PASTE(FOO__, func)(x)

We should use this kind of trick sparingly, since it gets confusing.
In our old design, we had to declare configuration structures (like
or_options_t) and variable tables (like option_vars_) separately,
and we used some magic to enforce their consistency (see
conftesting.h).

With this design, we write a single definition for the configuration
object and its fields, and use C macros to expand it either into a
structure, or a variable table.  Since they are both made from the
same source, they can't become inconsistent.

The two designs can coexist happily, and we can migrate from one to
the other at our convenience.
This version uses the enum rather than the type definitions, to
avoid layering violations and linking problems.
Here's an example of how we can use the new macros in confdecl.h to
declare a module-level configuration. This configuration isn't
actually "hooked up" to anything yet: it's just here as an example.
These settings allow doxygen to find and understand doxygen comments
in configuration definitions made using the macros in confdecl.h.
The subsysmgr code wants to use them.
We used to have only one boolean per subsystem, but we're about to
have a little more information.
The formats, when provided, are now added to the global config_mgr_t
objects.
These functions are in the subsystem, not in the config_format_t,
since they are about how the format is _used_, not about _what it
is_.
Copy link
Contributor

@teor2345 teor2345 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is a quick review of this PR.

src/app/main/subsysmgr.c Show resolved Hide resolved
src/app/main/subsysmgr.c Show resolved Hide resolved
src/app/main/subsysmgr.c Show resolved Hide resolved
src/app/main/subsysmgr.c Show resolved Hide resolved
src/app/main/subsysmgr.c Show resolved Hide resolved
src/app/main/subsysmgr.c Show resolved Hide resolved
src/lib/subsys/subsys.h Show resolved Hide resolved
src/lib/conf/confdecl.h Show resolved Hide resolved
@ghost ghost closed this May 25, 2021
@ghost ghost deleted the branch torproject:master May 25, 2021 12:56
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants