Fix everything that previously referred to src/or

2 files changed, 14 insertions, 14 deletions

diff --git a/doc/HACKING/Module.md b/doc/HACKING/Module.md
index 1028a029d9..6684e258df 100644
--- a/doc/HACKING/Module.md
+++ b/doc/HACKING/Module.md
@@ -12,9 +12,9 @@ Currently, there is only one module:
 
   - Directory Authority subsystem (dirauth)
 
-It is located in its own directory in `src/or/dirauth/`. To disable it, one
-need to pass `--disable-module-dirauth` at configure time. All modules are
-currently enabled by default.
+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.
 
 ## Build System ##
 
@@ -32,10 +32,10 @@ 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/or/include.am` file, locate the `MODULE_DIRAUTH_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.
+3. In the `src/core/include.am` file, locate the `MODULE_DIRAUTH_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.
 
    It is then **very** important to add your SOURCES variable to
    `src_or_libtor_testing_a_SOURCES` so the tests can build it.
@@ -51,7 +51,7 @@ always build everything in order to tests everything.
 ## Coding ##
 
 As mentioned above, a module must be isolated in its own directory (name of
-the module) in `src/or/`.
+the module) in `src/feature/`.
 
 There are couples of "rules" you want to follow:
 
@@ -87,10 +87,10 @@ There are couples of "rules" you want to follow:
   making the code much more difficult to follow/understand.
 
 * It is possible that you end up with code that needs to be used by the rest
-  of the code base but is still part of your module. As a good example, if you
-  look at `src/or/shared_random_client.c`: it contains code needed by the hidden
-  service subsystem but mainly related to the shared random subsystem very
-  specific to the dirauth module.
+  of the code base but is still part of your module. As a good example, if
+  you look at `src/feature/shared_random_client.c`: it contains code needed
+  by the hidden service subsystem but mainly related to the shared random
+  subsystem very specific to the dirauth module.
 
   This is fine but try to keep it as lean as possible and never use the same
   filename as the one in the module. For example, this is a bad idea and
@@ -102,7 +102,7 @@ There are couples of "rules" you want to follow:
 * When you include headers from the module, **always** use the full module
   path in your statement. Example:
 
-  `#include "dirauth/dirvote.h"`
+  `#include "feature/dirauth/dirvote.h"`
 
   The main reason is that we do **not** add the module include path by default
   so it needs to be specified. But also, it helps our human brain understand
diff --git a/doc/HACKING/Tracing.md b/doc/HACKING/Tracing.md
index 349aade23a..24fa761310 100644
--- a/doc/HACKING/Tracing.md
+++ b/doc/HACKING/Tracing.md
@@ -69,7 +69,7 @@ configure option:
 ## Instrument Tor ##
 
 This is pretty easy. Let's say you want to add a trace event in
-`src/or/rendcache.c`, you only have to add this include statement:
+`src/feature/rend/rendcache.c`, you only have to add this include statement:
 
 	#include "trace/events.h"