[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29211 [Core Tor/Tor]: Distribute config.c functionality across more modules
#29211: Distribute config.c functionality across more modules
--------------------------+------------------------------------
Reporter: nickm | Owner: nickm
Type: task | Status: assigned
Priority: Medium | Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points: 15
Reviewer: | Sponsor: Sponsor31-can
--------------------------+------------------------------------
Comment (by nickm):
Here is my current plan for the refactoring.
'''High-level goals'''
The end goal is that every module should define, via a hook in the
subsystem API, which variables it uses. The config_var_t structure is a
natural way to note this, since it maps a variable to a struct field, but
it has some problems:
* Its implementation is a huge pile of switch statements and special
cases
* It combines multiple responsibilities in one blob of code
* It is difficult to extend
* It describes a field in a _single_ structure, and is difficult to
aggregate into our target implementation, wherein every module has its own
configuration structure.
* Its current implementation depends on every type in the code that can
be used as a configuration variable. Since routerset_t is one such (high
level) type, and since we may expect other high-level types to exist in
the future, we need a better way to make this system extensible.
'''Code dependencies'''
src/lib/conf will be code that is used by modules that need to define
configurable items.
src/lib/confmgt/ will be generic code for manipulating configuration
variables in objects. It will handle reading and writing from strings to
struct members, and finding the appropriate struct members to read and
write, and so on. It will only be used by higher level modules that need
to do data-driven access to configuration. Configurable modules will just
need lib/conf and lib/susbsys.
src/app/config/ will do the work of collecting all the configurable
objects, reloading the configuration when appropriate, and notifying
different subsystems when the configuration has changed.
'''Branches so far'''
In #30893, I tried to get to 100% test coverage on confparse.c, since
that's the module that will be most affected by this refactoring. I
missed a couple of spots, but those will be fixed as part of the #30864
branch to avoid conflicts. This branch is now merged.
The next branch, #30864, extracts the lowest level of introspection code
from confparse.c: the code to manipulate typed values via a pointer and a
type definition. This functionality is in the typed_var module, and it's
not meant for direct use: it's a very low level api.
The next branch, #30914, wraps the typed_var API inside a struct_var API,
which instead of referring to a pointer to typed data, refers to a typed
member within a struct. It extracts this API from confparse.c, and cleans
it up a lot. Once again, it makes confparse.c simpler.
The next branch, #30935, refactors config_var_t a bit, and moves it to
lib/conf where it belongs. It is full of miscellaneous refactorings on
the confparse.c code and its users. Notably, it removes all code in
confparse.c or config.c that does "special-case" inspection of a
variable's type, and it removes the need to update tiny little macro
definitions all over the code. It also removes special-case handling of
"magic" variable names like those that start with __ and ___. Finally --
and necessarily for my sanity -- it refactors our horrible old handling of
TestingTorNetwork.
'''Next steps'''
The next major branch here will refactor config_fmt_t so that instead of
describing a mapping from variable names to a single struct, it describes
an extensible mapping from variable names to many structs. There will
need to be a corresponding "group of structs" object that confparse.c and
config.c use in place of their current or_options_t manipulation. That
will be done in #30866.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29211#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs