5 files changed, 164 insertions, 5 deletions
diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md
index 79a6a9f0ce..3711f70198 100644
--- a/doc/HACKING/CodingStandards.md
+++ b/doc/HACKING/CodingStandards.md
@@ -42,6 +42,23 @@ If you have changed build system components:
    - For example, if you have changed Makefiles, autoconf files, or anything
      else that affects the build system.
 
+License issues
+==============
+
+Tor is distributed under the license terms in the LICENSE -- in
+brief, the "3-clause BSD license".  If you send us code to
+distribute with Tor, it needs to be code that we can distribute
+under those terms.  Please don't send us patches unless you agree
+to allow this.
+
+Some compatible licenses include:
+
+  - 3-clause BSD
+  - 2-clause BSD
+  - CC0 Public Domain Dedication
+
+
+
 How we use Git branches
 =======================
 
@@ -417,3 +434,4 @@ the functions that call your function rely on it doing something, then your
 function should mention that it does that something in the documentation.  If
 you rely on a function doing something beyond what is in its documentation,
 then you should watch out, or it might do something else later.
+
diff --git a/doc/HACKING/CodingStandardsRust.md b/doc/HACKING/CodingStandardsRust.md
index 7c6405e624..d9496c08f7 100644
--- a/doc/HACKING/CodingStandardsRust.md
+++ b/doc/HACKING/CodingStandardsRust.md
@@ -324,12 +324,26 @@ Here are some additional bits of advice and rules:
             }
         }
 
-3. Pass only integer types and bytes over the boundary
+3. Pass only C-compatible primitive types and bytes over the boundary
 
-   The only non-integer type which may cross the FFI boundary is
+   Rust's C-compatible primitive types are integers and floats.
+   These types are declared in the [libc crate](https://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/index.html#types).
+   Most Rust objects have different [representations](https://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/index.html#types)
+   in C and Rust, so they can't be passed using FFI.
+
+   Tor currently uses the following Rust primitive types from libc for FFI:
+   * defined-size integers: `uint32_t`
+   * native-sized integers: `c_int`
+   * native-sized floats: `c_double`
+   * native-sized raw pointers: `* c_void`, `* c_char`, `** c_char`
+
+   TODO: C smartlist to Stringlist conversion using FFI
+
+   The only non-primitive type which may cross the FFI boundary is
    bytes, e.g. `&[u8]`.  This SHOULD be done on the Rust side by
-   passing a pointer (`*mut libc::c_char`) and a length
-   (`libc::size_t`).
+   passing a pointer (`*mut libc::c_char`). The length can be passed
+   explicitly (`libc::size_t`), or the string can be NUL-byte terminated
+   C string.
 
    One might be tempted to do this via doing
    `CString::new("blah").unwrap().into_raw()`. This has several problems:
diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md
index f919d08ec1..a0795076e0 100644
--- a/doc/HACKING/HelpfulTools.md
+++ b/doc/HACKING/HelpfulTools.md
@@ -4,6 +4,22 @@ Useful tools
 These aren't strictly necessary for hacking on Tor, but they can help track
 down bugs.
 
+Travis CI
+---------
+It's CI. Looks like this: https://travis-ci.org/torproject/tor.
+
+Runs automatically on Pull Requests sent to torproject/tor. You can set it up
+for your fork to build commits outside of PRs too:
+
+1. sign up for GitHub: https://github.com/join
+2. fork https://github.com/torproject/tor:
+   https://help.github.com/articles/fork-a-repo/
+3. follow https://docs.travis-ci.com/user/getting-started/#To-get-started-with-Travis-CI.
+   skip steps involving `.travis.yml` (we already have one).
+
+Builds should show up on the web at travis-ci.com and on IRC at #tor-ci on
+OFTC. If they don't, ask #tor-dev (also on OFTC).
+
 Jenkins
 -------
 
diff --git a/doc/HACKING/Module.md b/doc/HACKING/Module.md
new file mode 100644
index 0000000000..1028a029d9
--- /dev/null
+++ b/doc/HACKING/Module.md
@@ -0,0 +1,111 @@
+# Modules in Tor #
+
+This document describes the build system and coding standards when writing a
+module in Tor.
+
+## What is a module? ##
+
+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:
+
+  - 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.
+
+## Build System ##
+
+The changes to the build system are pretty straightforward.
+
+1. Locate in the `configure.ac` file this define: `m4_define(MODULES`. It
+   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
+   use the "disable module" approach instead of enabling them one by one. So,
+   by default, tor will build all the modules.
+
+   This will define the `HAVE_MODULE_<name>` statement which can be used in
+   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.
+
+   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.
+
+## Coding ##
+
+As mentioned above, a module must be isolated in its own directory (name of
+the module) in `src/or/`.
+
+There are couples of "rules" you want to follow:
+
+* Minimize as much as you can the number of entry points into your module.
+  Less is always better but of course that doesn't work out for every use
+  case. However, it is a good thing to always keep that in mind.
+
+* Do **not** use the `HAVE_MODULE_<name>` define outside of the module code
+  base. Every entry point should have a second definition if the module is
+  disabled. For instance:
+
+  ```
+  #ifdef HAVE_MODULE_DIRAUTH
+
+  int sr_init(int save_to_disk);
+
+  #else /* HAVE_MODULE_DIRAUTH */
+
+  static inline int
+  sr_init(int save_to_disk)
+  {
+    (void) save_to_disk;
+    return 0;
+  }
+
+  #endif /* HAVE_MODULE_DIRAUTH */
+
+  ```
+
+  The main reason for this approach is to avoid having conditional code
+  everywhere in the code base. It should be centralized as much as possible
+  which helps maintainability but also avoids conditional spaghetti code
+  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.
+
+  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
+  should never be done:
+
+    - `src/or/shared_random.c`
+    - `src/or/dirauth/shared_random.c`
+
+* When you include headers from the module, **always** use the full module
+  path in your statement. Example:
+
+  `#include "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
+  which part comes from a module or not.
+
+  Even **in** the module itself, use the full include path like above.
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index 6c8fa1331f..e70416c354 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -34,7 +34,7 @@ new Tor release:
 
    What about Coverity Scan?
 
-   What about clan scan-build?
+   What about clang scan-build?
 
    Does 'make distcheck' complain?