``` tor]$ grep -r 'main(' src/app src/app/config/or_options_st.h: int LogMessageDomains; /**< Boolean: Should we log the domain(s) in which src/app/main/main.c:/* Main entry point for the Tor process. Called from tor_main(), and by src/app/main/main.c:tor_run_main(const tor_main_configuration_t *tor_cfg) src/app/main/ntmain.c:static void nt_service_main(void); src/app/main/ntmain.c:nt_service_main(void) src/app/main/ntmain.c: * from those given to main() function. src/app/main/ntmain.c: nt_service_main(); src/app/main/tor_main.c: * \brief Stub module containing a main() function. src/app/main/tor_main.c: * tests, which have their own main()s, can link against main.c. src/app/main/tor_main.c:int tor_main(int argc, char *argv[]); src/app/main/tor_main.c:/** We keep main() in a separate file so that our unit tests can use src/app/main/tor_main.c:main(int argc, char *argv[]) src/app/main/tor_main.c: r = tor_main(argc, argv); $ cat src/app/main/tor_main.c ... ``` This is likely the main entry code for Tor. (Hey, tell me when it's time to shut up, if you're a hacker.) These files are like the genes of tor: they make it all work when you finally 'conceive' the tor process by running it, the kernel having electronic sex (I'm a prude myself) with the harddrive, sending its data regions through the various processes of the system loader, until the kernel process grows into a confused little application. And they were handmade by software developers like the famous Jacob Appelbaum, who is unfortunately the same age as me! He doesn't have _that_ big a beard, but he does have glasses, so his beard is big enough to be a coder. ``` /* Copyright 2001-2004 Roger Dingledine. * Copyright (c) 2004-2006, Roger Dingledine, Nick Mathewson. * Copyright (c) 2007-2020, The Tor Project, Inc. */ /* See LICENSE for licensing information */ ``` This stuff people put at the top of their source code to support various lawyer heroes they know. Often richard stallman gets a big chunk up here. Tor is kind and refers us to another file for details rather than making us scroll past it all. ``` #include "orconfig.h" #ifdef ENABLE_RESTART_DEBUGGING #include <stdlib.h> #endif ``` Header files. orconfig.h looks like some of that system-specific stuff that `./configure` might have generated. The #ifdef/#endif's basically indicate that ./configure can enable or disable the region between them. "stdlib" is used for a wide variety of functions. ``` /** * \file tor_main.c * \brief Stub module containing a main() function. * * We keep the main function in a separate module so that the unit * tests, which have their own main()s, can link against main.c. **/ int tor_main(int argc, char *argv[]); ``` This is a very clear description of the file we are looking at. The commenting style is well-accepted, and quite easy for developers to look at it, because it is so normal. The comment implies that the _real_ guts are going to be in main.c . We can look at that file after this one. ``` /** We keep main() in a separate file so that our unit tests can use * functions from main.c. */ int main(int argc, char *argv[]) ``` Here they said a very similar thing, but put the comment on the main function instead of the tor_main function. This is because programmers can get very confused after spending their lives staring at blinking rectangles instead of talking to other people. It's possible a software developer would only see the thing they are looking for, and not the things around it! Additionally, software developers learn to be very obsessive compulsive about rigorous consistency in the structures they design, because if they don't do that when working inside a computer the computer can develop a bad issue of smoke leaving its cpu. Comments don't affect the cpu. ``` { int r; ``` This defines a variable "r", saying it is an integer, and that nobody knows what it will be used for quite yet. ``` #ifdef ENABLE_RESTART_DEBUGGING int restart_count = getenv("TOR_DEBUG_RESTART") ? 1 : 0; again: #endif ``` Here's that mysterious use of `<stdlib.h>`! `getenv` is a function from stdlib that gets a variable from the environment. If this feature is enabled, the user can set `TOR_DEBUG_RESTART` to control the value of restart_count, _without changing or recompiling any code_! Miraculous! ``` r = tor_main(argc, argv); ``` This hands off control of the system to the tor_main function and is the _only thing_ actually being done here. There's no need to look any more at this file. It's basically saying that `tor_main` is the real `main`, over and over again. ``` tor]$ grep -r 'tor_main(' . ./ChangeLog: return from the tor_main() function, rather than calling the ./ReleaseNotes: return from the tor_main() function, rather than calling the ./src/app/main/main.c:/* Main entry point for the Tor process. Called from tor_main(), and by ./src/app/main/tor_main.c:int tor_main(int argc, char *argv[]); ./src/app/main/tor_main.c: r = tor_main(argc, argv); ./src/feature/api/tor_api.c:tor_main(int argc, char *argv[]) ./src/feature/api/tor_api.h:int tor_main(int argc, char **argv); ``` `tor_main` appears to be in tor_api.c . If you want to memorize the basics of how tor works, that's the next file to look in. That's all for now, folks!