nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-03 17:13:33 +01:00
Code Issues Packages Projects Releases Wiki Activity

config.md: suggestions from teor

Browse Source
This commit is contained in:
Nick Mathewson 2019-11-21 08:26:12 -05:00
parent 0e4e96b9bf
commit 55fac8dafc
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
src/lib/conf/config.md
View File

@ -48,12 +48,12 @@ usage, see crypto_options.inc or mainloop_state.inc.
After using those macros, you must tell the subsystem management After using those macros, you must tell the subsystem management
code about your module's configuration/state. code about your module's configuration/state.
If you're writing configuration code, you'll need a function that If you're writing configuration code, you'll need a function that receives
receives the configuration object, and acts upon it. This function the configuration object, and acts upon it. This function needs to be safe
needs to be safe to call multiple times, since Tor will reconfigure to call multiple times, since Tor will reconfigure its subsystems whenever it
its subsystems whenever it, or whenever it restarts in process. re-reads the torrc, gets a configuration change from a controller, or
This function goes in your subsystem's subsys_fns_t.set_options restarts in process. This function goes in your subsystem's
field. subsys_fns_t.set_options field.
If you're writing state code, you'll need a function that receives If you're writing state code, you'll need a function that receives
state (subsys_fns_t.set_state), and a function that flushes the state (subsys_fns_t.set_state), and a function that flushes the
@ -89,10 +89,10 @@ subsystem manager code (subsysmgr.c) to pass the corresponding
configuration or state objects to each module that has one. configuration or state objects to each module that has one.
Note that the top level code does not have easy access to the Note that the top level code does not have easy access to the
configuration objects used by the sub-modules. This is by design. configuration objects used by the sub-modules. This is by design. A
A module _may_ expose its configuration or state object, if it module _may_ expose some or all of its configuration or state object via
likes, but if it does not, that object should be considered accessor functions, if it likes, but if it does not, that object should
module-local. be considered module-local.
## Adding new types ## Adding new types
@ -113,8 +113,8 @@ used with the macros in confdecl.h.
## Legacy configuration and state ## Legacy configuration and state
As of this writing, most of the configuration and state is still As of this writing (November 2019), most of the configuration and state is
handled directly in config.c and statefile.c, and stored in the still handled directly in config.c and statefile.c, and stored in the
monolithic structures or_options_t and or_state_t respectively. monolithic structures or_options_t and or_state_t respectively.
These top-level structures are accessed with get_options() and These top-level structures are accessed with get_options() and