[tor-commits] [tor/master] doc/HACKING: Update Module.md for the relay module

[nickm@xxxxxxxxxxxxxx]

commit 0973575737be20c20897bf674704689478092f38
Author: teor <teor@xxxxxxxxxxxxxx>
Date:   Thu Oct 17 16:12:24 2019 +1000

    doc/HACKING: Update Module.md for the relay module
    
    Also fix some typos, and delete some obsolete instructions.
    
    Part of 32123.
---
 doc/HACKING/Module.md | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/doc/HACKING/Module.md b/doc/HACKING/Module.md
index 9cf36090b..3a07d0c63 100644
--- a/doc/HACKING/Module.md
+++ b/doc/HACKING/Module.md
@@ -8,13 +8,18 @@ module in Tor.
 In the context of the tor code base, a module is a subsystem that we can
 selectively enable or disable, at `configure` time.
 
-Currently, there is only one module:
+Currently, tor has these modules:
 
+  - Relay subsystem (relay)
   - Directory Authority subsystem (dirauth)
 
-It is located in its own directory in `src/feature/dirauth/`. To disable it,
-one need to pass `--disable-module-dirauth` at configure time. All modules
-are currently enabled by default.
+dirauth is located in its own directory in `src/feature/dirauth/`.
+
+Relay is located in directories named `src/*/*relay` and `src/*/*dircache`,
+which are being progressively refactored and disabled.
+
+To disable a module, pass `--disable-module-{dirauth,relay}` at configure
+time. All modules are currently enabled by default.
 
 ## Build System ##
 
@@ -24,7 +29,7 @@ The changes to the build system are pretty straightforward.
    contains a list (white-space separated) of the module in tor. Add yours to
    the list.
 
-2. Use the `AC_ARG_ENABLE([module-dirauth]` template for your new module. We
+2. Use the `AC_ARG_ENABLE([module-relay]` template for your new module. We
    use the "disable module" approach instead of enabling them one by one. So,
    by default, tor will build all the modules.
 
@@ -32,7 +37,7 @@ The changes to the build system are pretty straightforward.
    the C code to conditionally compile things for your module. And the
    `BUILD_MODULE_<name>` is also defined for automake files (e.g: include.am).
 
-3. In the `src/core/include.am` file, locate the `MODULE_DIRAUTH_SOURCES`
+3. In the `src/core/include.am` file, locate the `MODULE_RELAY_SOURCES`
    value.  You need to create your own `_SOURCES` variable for your module
    and then conditionally add the it to `LIBTOR_A_SOURCES` if you should
    build the module.
@@ -40,18 +45,14 @@ The changes to the build system are pretty straightforward.
    It is then **very** important to add your SOURCES variable to
    `src_or_libtor_testing_a_SOURCES` so the tests can build it.
 
-4. Do the same for header files, locate `ORHEADERS +=` which always add all
-   headers of all modules so the symbol can be found for the module entry
-   points.
-
 Finally, your module will automatically be included in the
-`TOR_MODULES_ALL_ENABLED` variable which is used to build the unit tests. They
-always build everything in order to tests everything.
+`TOR_MODULES_ALL_ENABLED` variable which is used to build the unit tests.
+They always build everything in order to test everything.
 
 ## Coding ##
 
-As mentioned above, a module must be isolated in its own directory (name of
-the module) in `src/feature/`.
+As mentioned above, a module should be isolated in its own directories,
+suffixed with the name of the module, in `src/*/`.
 
 There are couples of "rules" you want to follow:
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits