Doxygen: remove /** and **/ from all .dox files

This is an automatically generated commit, made with:

find src -name '*.dox' | \
   xargs  perl -i -ne 'print unless (m#^\s*/?\*\*/?\s*$#);'
This commit is contained in:
Nick Mathewson 2019-11-15 09:23:51 -05:00
parent 625ad65382
commit 3a7369d0cf
74 changed files with 0 additions and 149 deletions

View file

@ -1,8 +1,6 @@
/**
@dir /app
@brief app: top-level entry point for Tor
The "app" directory has Tor's main entry point and configuration logic,
and is responsible for initializing and managing the other modules in
Tor.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /app/config
@brief app/config: Top-level configuration code
Refactoring this module is a work in progress, see
[ticket 29211](https://trac.torproject.org/projects/tor/ticket/29211).
**/

View file

@ -1,4 +1,2 @@
/**
@dir /app/main
@brief app/main: Entry point for tor.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /core
@brief core: main loop and onion routing functionality
@ -17,4 +16,3 @@ and one high-level piece:
- \refdir{core/or} -- Implements onion routing itself.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /core/crypto
@brief core/crypto: Tor-specific cryptography
This module implements Tor's circuit-construction crypto and Tor's
relay crypto.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /core/mainloop
@brief core/mainloop: Non-onion-routing mainloop functionality
@ -9,4 +8,3 @@ The layering here is imperfect: the code here was split from \refdir{core/or}
without refactoring how the two modules call one another. Probably many
functions should be moved and refactored.
**/

View file

@ -1,4 +1,3 @@
/**
@dir core/or
@brief core/or: **Onion routing happens here!**
@ -61,4 +60,3 @@ encrypt, route, and interpret relay cells.
`scheduler.c`
: Decides which channel/circuit pair is ready to receive the next cell.
**/

View file

@ -1,4 +1,3 @@
/**
@tableofcontents
@page dataflow Data flow in the Tor process
@ -235,4 +234,3 @@ queue the next cell.
(This logic applies to outgoing relay cells only; incoming relay cells
are processed as they arrive.)
**/

View file

@ -1,8 +1,6 @@
/**
@dir /core/proto
@brief core/proto: Protocol encoding/decoding
These functions should (but do not always) exist at a lower level than most
of the rest of core.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /feature/api
@brief feature/api: In-process interface to starting/stopping Tor.
**/

View file

@ -1,7 +1,5 @@
/**
@dir /feature/client
@brief feature/client: Client-specific code
(There is also a bunch of client-specific code in other modules.)
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/control
@brief feature/control: Controller API.
@ -7,4 +6,3 @@ thread, if you're running Tor in-process) can use to configure and control
Tor while it is running. The current protocol is documented in
[control-spec.txt](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt).
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/dirauth
@brief feature/dirauth: Directory authority implementation.
@ -8,4 +7,3 @@ The directory protocol is specified in
[dir-spec.txt](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt).
**/

View file

@ -1,8 +1,6 @@
/**
@dir /feature/dircache
@brief feature/dircache: Run as a directory cache server
This module handles the directory caching functionality that all relays may
provide, for serving cached directory objects to objects.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/dirclient
@brief feature/dirclient: Directory client implementation.
@ -6,4 +5,3 @@ The code here is used by all Tor instances that need to download directory
information. Currently, that is all of them, since even authorities need to
launch downloads to learn about relays that other authorities have listed.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/dircommon
@brief feature/dircommon: Directory client and server shared code
@ -6,4 +5,3 @@ This module has the code that directory clients (anybody who download
information about relays) and directory servers (anybody who serves such
information) share in common.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/dirparse
@brief feature/dirparse: Parsing Tor directory objects
@ -7,4 +6,3 @@ We define a number of "directory objects" in
all of them using a common line-oriented meta-format. This module is used by
other parts of Tor to parse them.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature
@brief feature: domain-specific modules
@ -6,4 +5,3 @@ The "feature" directory has modules that Tor uses only for a particular
role or service, such as maintaining/using an onion service, operating as a
relay or a client, or being a directory authority.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/hibernate
@brief feature/hibernate: Bandwidth accounting and hibernation (!)
@ -13,4 +12,3 @@ The two features are related only in the sense that "soft hibernation" (being
almost out of ) is very close to the "shutting down" state. But it would be
better in the long run to make the two completely separate.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/hs
@brief feature/hs: v3 (current) onion service protocol
@ -7,4 +6,3 @@ as specified in
[rend-spec-v3.txt](https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt).
**/

View file

@ -1,5 +1,3 @@
/**
@dir /feature/hs_common
@brief feature/hs_common: Common to v2 (old) and v3 (current) onion services
**/

View file

@ -1,5 +1,3 @@
/**
@dir /feature/keymgt
@brief feature/keymgt: Store keys for relays, authorities, etc.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /feature/nodelist
@brief feature/nodelist: Download and manage a list of relays
**/

View file

@ -1,6 +1,4 @@
/**
@dir /feature/relay
@brief feature/relay: Relay-specific code
(There is also a bunch of relay-specific code in other modules.)
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/rend
@brief feature/rend: version 2 (old) hidden services
@ -6,4 +5,3 @@ This directory implements the v2 onion service protocol,
as specified in
[rend-spec-v2.txt](https://gitweb.torproject.org/torspec.git/tree/rend-spec-v2.txt).
**/

View file

@ -1,4 +1,3 @@
/**
@dir /feature/stats
@brief feature/stats: Relay statistics. Also, port prediction.
@ -9,4 +8,3 @@ Additionally, it contains predict_ports.c, which remembers which ports we've
visited recently as a client, so we can make sure we have open circuits that
support them.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/arch
@brief lib/arch: Compatibility code for handling different CPU architectures.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/buf
@brief lib/buf: An efficient byte queue.
@ -12,4 +11,3 @@ The buf_t type is also reasonable for use in constructing long strings.
See \refdir{lib/net} for networking code that uses buf_t, and
\refdir{lib/tls} for cryptographic code that uses buf_t.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/cc
@brief lib/cc: Macros for managing the C compiler and language.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/compress
@brief lib/compress: Wraps several compression libraries
Currently supported are zlib (mandatory), zstd (optional), and lzma
(optional).
**/

View file

@ -1,5 +1,3 @@
/**
@dir /lib/conf
@brief lib/conf: Types and macros for declaring configuration options.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/confmgt
@brief lib/confmgt: Parse, encode, manipulate configuration files.
@ -6,4 +5,3 @@ This logic is used in common by our state files (statefile.c) and
configuration files (config.c) to manage a set of named, typed fields,
reading and writing them to disk and to the controller.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/container
@brief lib/container: Hash tables, dynamic arrays, bit arrays, etc.
@ -48,4 +47,3 @@ cryptographic siphash24g function to extract hashes.
<!-- TODO: WRITE about bloom filters, namemaps, bit-arrays, order functions.
-->
**/

View file

@ -1,4 +1,3 @@
/**
@page certificates Certificates in Tor.
@ -29,4 +28,3 @@ documents that include keys and which are signed by keys. You can
consider these documents to be an additional kind of certificate if you
want.)
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/crypt_ops
@brief lib/crypt_ops: Cryptographic operations.
@ -136,4 +135,3 @@ secret object to disk, encrypted with a passphrase. The crypto_pwbox
and crypto_unpwbox functions do so in a way that's likely to be
readable by future versions of Tor.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/ctime
@brief lib/ctime: Constant-time code to avoid side-channels.
@ -13,4 +12,3 @@ consider calls to memcmp() to be in error, we require that code that actually
doesn't need to be constant-time to use the fast_memeq() / fast_memneq() /
fast_memcmp() aliases instead.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/defs
@brief lib/defs: Lowest-level constants, used in many places.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/dispatch
@brief lib/dispatch: In-process message delivery.
@ -13,4 +12,3 @@ This is not a fancy multi-threaded many-to-many dispatcher as you may be used
to from more sophisticated architectures: this dispatcher is intended only
for use in improving Tor's architecture.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/encoding
@brief lib/encoding: Encoding data in various forms, types, and transformations
Here we have time formats (timefmt.c), quoted strings (qstring.c), C strings
(string.c) base-16/32/64 (binascii.c), and more.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/err
@brief lib/err: Lowest-level error handling code.
@ -12,4 +11,3 @@ There are three kinds of users for the functions in this module:
* Code that needs signal-safe error reporting.
* Higher-level error handling code.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/evloop
@brief lib/evloop: Low-level event loop.
@ -6,4 +5,3 @@ This modules has tools to manage the [libevent](https://libevent.org/) event
loop and related functionality, in order to implement asynchronous
networking, timers, periodic events, and other scheduling tasks.
**/

View file

@ -1,4 +1,3 @@
/**
@page time_periodic Time and periodic events in Tor
@ -75,4 +74,3 @@ platforms. (The timers.c module uses William Ahern's timeout.c
implementation as its backend, which is based on a hierarchical timing
wheel algorithm. It's cool stuff; check it out.)
**/

View file

@ -1,7 +1,5 @@
/**
@dir /lib/fdio
@brief lib/fdio: Code to read/write on file descriptors.
(This module also handles sockets, on platforms where a socket is not a kind
of fd.)
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/fs
@brief lib/fs: Files, filenames, directories, etc.
@ -8,4 +7,3 @@ operating-system-specific filesystem access.
It also contains a set of convenience functions for safely writing to files,
creating directories, and so on.
**/

View file

@ -1,5 +1,3 @@
/**
@dir /lib/geoip
@brief lib/geoip: IP-to-country mapping
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/intmath
@brief lib/intmath: Integer mathematics.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib
@brief lib: low-level functionality.
@ -130,4 +129,3 @@ If you are using platform-specific `ifdef`s to manage compatibility
issues among platforms, you should probably consider whether you can
put your code into lib.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/lock
@brief lib/lock: Simple locking support.
This module is more low-level than the rest of the threading code, since it
is needed by more intermediate-level modules.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/log
@brief lib/log: Log messages to files, syslogs, etc.
@ -9,4 +8,3 @@ specifically written to avoid having to log, because the logging module
depends on it.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/malloc
@brief lib/malloc: Wrappers and utilities for memory management.
@ -75,4 +74,3 @@ using the FREE_AND_NULL macro, as follows:
#define x_free(ptr) FREE_AND_NULL(x_t, x_free_, (ptr))
```
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/math
@brief lib/math: Floating-point math utilities.
This module includes a bunch of floating-point compatibility code, and
implementations for several probability distributions.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/memarea
@brief lib/memarea: A fast arena-style allocator.
@ -27,4 +26,3 @@ The allocation functions `memarea_alloc()`, `memarea_alloc_zero()`,
to the similarly-named malloc() functions. There is intentionally no
`memarea_free()` or `memarea_realloc()`.
**/

View file

@ -1,7 +1,5 @@
/**
@dir /lib/meminfo
@brief lib/meminfo: Inspecting malloc() usage.
Only available when malloc() provides mallinfo() or something similar.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/net
@brief lib/net: Low-level network-related code.
This module includes address manipulation, compatibility wrappers,
convenience functions, and so on.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/osinfo
@brief lib/osinfo: For inspecting the OS version and capabilities.
@ -7,4 +6,3 @@ system they are running. We shouldn't make decisions based on the output of
these checks: instead, we should have more specific checks, either at compile
time or run time, based on the observed system behavior.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/process
@brief lib/process: Launch and manage subprocesses.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/pubsub
@brief lib/pubsub: Publish-subscribe message passing.
@ -13,4 +12,3 @@ would be clumsy and tend to complicate the call graph.)
See pubsub.c for more information.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/sandbox
@brief lib/sandbox: Linux seccomp2-based sandbox.
@ -14,4 +13,3 @@ A better architecture would put the responsibility for invoking tricky system
calls (like open()) in another, less restricted process, and give that
process responsibility for enforcing our sandbox rules.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/smartlist_core
@brief lib/smartlist_core: Minimal dynamic array implementation
@ -9,4 +8,3 @@ There are higher-level pieces in \refdir{lib/container} but
the ones in lib/smartlist_core are used by the logging code, and therefore
cannot use the logging code.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/string
@brief lib/string: Low-level string manipulation.
@ -12,4 +11,3 @@ in the rest of the codebase.
Any string function high-level enough to need logging belongs in a
higher-level module.
**/

View file

@ -1,4 +1,3 @@
/**
@page strings String processing in Tor

View file

@ -1,4 +1,3 @@
/**
@page initialization Initialization and shutdown
@ -74,4 +73,3 @@ must occur _after_ the initialization process, during configuration.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/subsys
@brief lib/subsys: Types for declaring a "subsystem".
@ -31,4 +30,3 @@ that are initialized from `tor_init()` or `run_tor_main_loop()` or
these to subsystems over time; please don't add any new code that follows
this pattern.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/term
@brief lib/term: Terminal operations (password input).
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/testsupport
@brief lib/testsupport: Helpers for test-only code and for function mocking.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/thread
@brief lib/thread: Mid-level threading.
@ -6,4 +5,3 @@ This module contains compatibility and convenience code for multithreading,
except for low-level locks (which are in \refdir{lib/lock} and
workqueue/threadpool code (which belongs in \refdir{lib/evloop}.)
**/

View file

@ -1,4 +1,3 @@
/**
@page threading Threading in Tor
@ -25,4 +24,3 @@ Try to minimize sharing between threads: it is usually best to simply
make the worker "own" all the data it needs while the work is in
progress, and to give up ownership when it's complete.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/time
@brief lib/time: Higher-level time functions
@ -8,4 +7,3 @@ wrappers for them to try to improve efficiency.
For "what time is it" in UTC, see \refdir{lib/wallclock}. For parsing and
encoding times and dates, see \refdir{lib/encoding}.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/tls
@brief lib/tls: TLS library wrappers
@ -10,4 +9,3 @@ It also implements the logic for some legacy TLS protocol usage we used to
support in old versions of Tor, involving conditional delivery of certificate
chains (v1 link protocol) and conditional renegotiation (v2 link protocol).
**/

View file

@ -1,8 +1,6 @@
/**
@dir /lib/trace
@brief lib/trace: Function-tracing functionality API.
This module is used for adding "trace" support (low-granularity function
logging) to Tor. Right now it doesn't have many users.
**/

View file

@ -1,4 +1,2 @@
/**
@dir /lib/version
@brief lib/version: holds the current version of Tor.
**/

View file

@ -1,4 +1,3 @@
/**
@dir /lib/wallclock
@brief lib/wallclock: Inspect and manipulate the current time.
@ -10,4 +9,3 @@ For versions of the time that are more local, more monotonic, or more
accurate, see \refdir{lib/time}. For parsing and encoding times and dates,
see \refdir{lib/encoding}.
**/

View file

@ -1,4 +1,3 @@
/**
@mainpage Tor source reference
@tableofcontents
@ -42,9 +41,7 @@ Tor repository.
@subpage time_periodic
**/
/**
@page intro A high-level overview
@tableofcontents
@ -144,4 +141,3 @@ more connection types.
A 'Node' (node_t) is a view of a Tor instance's current knowledge and opinions
about a Tor relay or bridge.
**/

View file

@ -1,8 +1,6 @@
/**
@dir /tools
@brief tools: other command-line tools for use with Tor.
The "tools" directory has a few other programs that use Tor, but are not part
of the main Tor binary.
**/