Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Tor
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Container Registry
Model registry
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
The Tor Project
Core
Tor
Commits
e39423c7
Commit
e39423c7
authored
5 years ago
by
Nick Mathewson
Browse files
Options
Downloads
Patches
Plain Diff
Remove 01e-os-compat: the module docs cover this much better.
parent
6744f6b6
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/HACKING/design/01e-os-compat.md
+0
-50
0 additions, 50 deletions
doc/HACKING/design/01e-os-compat.md
with
0 additions
and
50 deletions
doc/HACKING/design/01e-os-compat.md
deleted
100644 → 0
+
0
−
50
View file @
6744f6b6
## OS compatibility functions ##
We've got a bunch of functions to wrap differences between various
operating systems where we run.
### The filesystem ###
We wrap the most important filesystem functions with load-file,
save-file, and map-file abstractions declared in util.c or compat.c. If
you're messing about with file descriptors yourself, you might be doing
things wrong. Most of the time, write_str_to_file() and
read_str_from_file() are all you need.
Use the check_private_directory() function to create or verify the
presence of directories, and tor_listdir() to list the files in a
directory.
Those modules also have functions for manipulating paths a bit.
### Networking ###
Nearly all the world is on a Berkeley sockets API, except for
windows, whose version of the Berkeley API was corrupted by late-90s
insistence on backward compatibility with the
sort-of-berkeley-sort-of-not add-on
*thing*
that was WinSocks.
What's more, everybody who implemented sockets realized that select()
wasn't a very good way to do nonblocking IO... and then the various
implementations all decided to so something different.
You can forget about most of these differences, fortunately: We use
libevent to hide most of the differences between the various networking
backends, and we add a few of our own functions to hide the differences
that Libevent doesn't.
To create a network connection, the right level of abstraction to look
at is probably the connection_t system in connection.c. Most of the
lower level work has already been done for you. If you need to
instantiate something that doesn't fit well with connection_t, you
should see whether you can instantiate it with connection_t anyway -- or
you might need to refactor connection.c a little.
Whenever possible, represent network addresses as tor_addr_t.
### Process launch and monitoring ###
Launching and/or monitoring a process is tricky business. You can use
the mechanisms in procmon.c and tor_spawn_background(), but they're both
a bit wonky. A refactoring would not be out of order.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment