[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