[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29209 [Core Tor/Tor]: Reduce visibility of more data type internals
#29209: Reduce visibility of more data type internals
----------------------------------------+----------------------------------
Reporter: nickm | Owner: (none)
Type: task | Status: needs_review
Priority: Medium | Milestone: Tor:
| 0.4.1.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: technical-debt refactoring | Actual Points: 3.5
Parent ID: | Points: 15
Reviewer: | Sponsor: Sponsor31-can
----------------------------------------+----------------------------------
Changes (by asn):
* status: new => needs_review
* actualpoints: => 3.5
Comment:
OK, I finally have something to show here:
https://github.com/torproject/tor/pull/929
So basically this branch does the following:
- Moves `crypt_path_t` related functions to its own file
`src/core/or/crypt_path.c`. Previously they were all over the place, even
tho they were cpath-specific.
- Starts splitting `crypt_path_t` into a public struct and a private
struct (using an opaque pointer).
- Moves `crypt_path_t.crypto` to the private part of the struct by
defining appropriate functions for doing circuit crypto.
This took much longer than anticipated because I first experimented with
encapsulating others parts of `crypt_path_t` before deciding to go with
`crypto`. In particular, I first started hiding `deliver_window` and
`package_window` but I quickly realized that this would cause lots of
conflicts with #26288. I think after #26288 gets merged, these two fields
might be the next candidates for hiding.
Now in terms of general notes, this project took me more than 3 days of
careful refactoring work, and I've only hided like 10% of the cpath
structure. Hiding the whole structure is far far away since there are
quite complicated structures involved like `extend_info_t`.
In terms of future goals here, I think hiding `extend_info_t` into its own
interface would be quite convenient since that structure is used and poked
in weird ways all over the codebase. Furthermore, that would mean we can
eventually encapsulate `crypt_path_t` even better. Other plausible medium-
term targets would be structures like `tor_cert_t` which are mostly
hidden, but not completely.
I also added some TODO notes in the top of `crypt_path.c` with more cpath-
specific things we can move without too much trouble.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29209#comment:3>
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