[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #31634 [Core Tor/Tor]: Check .may_include order and tor subsystem init order are compatible

#31634: Check .may_include order and tor subsystem init order are compatible
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  nickm
     Type:  enhancement                          |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  diagnostics, 042-should?,            |  Actual Points:
  practracker                                    |
Parent ID:                                       |         Points:  2
 Reviewer:  teor                                 |        Sponsor:
                                                 |  Sponsor31-can
-------------------------------------------------+-------------------------
Changes (by nickm):

 * status:  assigned => needs_review
 * keywords:  diagnostics, 042-should, practracker => diagnostics,
     042-should?, practracker
 * reviewer:   => teor


Comment:

 I have started this, but I believe it is bigger than we should do in
 0.4.2, and we should defer part of it till 0.4.3.  Here is why:

    * Our subsystems do not currently to our directory structures.
 Notably, these subsystems are defined in with names that do not match
 their locations: btrack, network, ocirc_event, oconn_event, relay,
 threads, tortls, winprocess.

    * Our subsystem order does not currently match the topology very well
 at all: there are four discontinuities on the ordering.  I think they are
 caused by: btrack, compress, winprocess, threads.  We should re-order
 these, but doing so will require us to re-organize some of our code.  That
 seems like a stability risk.

 I have checked in a work-in-progress version of the code to do these
 checks as `ticket31634`.  Do you think it's reasonable to defer to 0.4.3
 based on the above reasoning?  If not, please re-assign to me for 0.4.2,
 but this just got bigger than we anticipated.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31634#comment:7>
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