[tor-commits] [tor/master] Turn the "dataflow" document into a doxygen page.

[nickm@xxxxxxxxxxxxxx]

commit 3ae87c3c7f1fb79744a343c0033afa24520a56d6
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Wed Nov 6 12:50:57 2019 -0500

    Turn the "dataflow" document into a doxygen page.
---
 .../design/02-dataflow.md => src/core/or/dataflow.dox    | 14 ++++++++------
 src/mainpage.dox                                         | 16 +++++++++++++++-
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/doc/HACKING/design/02-dataflow.md b/src/core/or/dataflow.dox
similarity index 97%
rename from doc/HACKING/design/02-dataflow.md
rename to src/core/or/dataflow.dox
index 39f21a908..3b32bb30f 100644
--- a/doc/HACKING/design/02-dataflow.md
+++ b/src/core/or/dataflow.dox
@@ -1,5 +1,7 @@
+/**
+@tableofcontents
 
-## Data flow in the Tor process ##
+@page dataflow Data flow in the Tor process
 
 We read bytes from the network, we write bytes to the network.  For the
 most part, the bytes we write correspond roughly to bytes we have read,
@@ -7,9 +9,7 @@ with bits of cryptography added in.
 
 The rest is a matter of details.
 
-![Diagram of main data flows in Tor](./diagrams/02/02-dataflow.png "Diagram of main data flows in Tor")
-
-### Connections and buffers: reading, writing, and interpreting. ###
+### Connections and buffers: reading, writing, and interpreting.
 
 At a low level, Tor's networking code is based on "connections".  Each
 connection represents an object that can send or receive network-like
@@ -79,7 +79,7 @@ wide variety of reasons, including:
    * For some connection types, reading is disabled when the inbuf is
      too full.
    * Reading/writing is temporarily disabled on connections that have
-     recently read/written enough data up to their bandwidth 
+     recently read/written enough data up to their bandwidth
    * Reading is disabled on connections when reading more data from them
      would require that data to be buffered somewhere else that is
      already full.
@@ -208,7 +208,7 @@ next channel in sequence with `append cell_to_circuit_queue()`.  This
 places the cell on a per-circuit queue for cells headed out on that
 particular channel.
 
-### Sending cells on circuits: the complicated bit. ###
+### Sending cells on circuits: the complicated bit.
 
 Relay cells are queued onto circuits from one of two (main) sources:
 reading data from edge connections, and receiving a cell to be relayed
@@ -234,3 +234,5 @@ queue the next cell.
 
 (This logic applies to outgoing relay cells only; incoming relay cells
 are processed as they arrive.)
+
+**/
diff --git a/src/mainpage.dox b/src/mainpage.dox
index 02ce8675e..eb29eb5fa 100644
--- a/src/mainpage.dox
+++ b/src/mainpage.dox
@@ -1,7 +1,9 @@
 /**
 @mainpage Tor source reference
 
-@section intro Welcome to Tor
+@tableofcontents
+
+@section welcome Welcome to Tor
 
 This documentation describes the general structure of the Tor codebase, how
 it fits together, what functionality is available for extending Tor, and
@@ -24,6 +26,18 @@ development tools, see
 [doc/HACKING](https://gitweb.torproject.org/tor.git/tree/doc/HACKING) in the
 Tor repository.
 
+@section topics Topic-related documentation
+
+@subpage intro
+
+@subpage dataflow
+**/
+
+/**
+@page intro A high-level overview
+
+@tableofcontents
+
 @section highlevel The very high level
 
 Ultimately, Tor runs as an event-driven network daemon: it responds to

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