Re: [tor-bugs] #31851 [Core Tor/Tor]: Allow Tor to be compiled without support for relay mode

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#31851: Allow Tor to be compiled without support for relay mode
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:  teor
     Type:  task          |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-design    |  Actual Points:  0.2
Parent ID:                |         Points:  5
 Reviewer:  nickm         |        Sponsor:  Sponsor31-can
--------------------------+------------------------------------

Comment (by nickm):

 Replying to [comment:3 teor]:
 >
 > > In general, as we are disabling code, we should remember that it is
 better to only stub out code that is called from higher-level modules.
 When code is called from lower-level modules, we should look for a way to
 remove the inverted dependency entirely.
 >
 > Is there a quick guide or picture of our higher-level and lower-level
 modules?

 There is a little of this in CodeStructure.md , but it needs to be more
 explicit.  I hope we'll get to this with the tor-guts revisions.

 The layers are, from higher to lower level:
 {{{
 App -> Feature -> Core -> Lib
 }}}

 The Lib layer is well-factored internally.  The core, feature, and app
 layers are still not.

 > How should we prioritise the modules?
 > 1. Quick wins
 > 2. Easy stubs for lower-level modules
 > 3. Stubs and remove low-high dependencies for higher-level modules

 I think "quick wins" is a good place to start.  If we can go lower-level
 towards higher-level, we will be glad we did, but we won't always have the
 option.  I also think that it might be a good idea to start with
 "feature/dircache" and "feature/relay" themselves, and move outwards from
 there.

 When I approached this kind of refactoring with lib, I found that it was
 often hard to anticipate what would be hard to extract and what would be
 easy to extract, so I had a lot of false starts where I started on one
 approach, and then binned it in favor of another.  I think a similar
 exploratory approach might be helpful to me here.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31851#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

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