-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename the public ptrace_* functions. #692
Conversation
Unlike in C, we have namespacing in Rust. Renaming the functions allows us to avoid a `use nix::sys::ptrace::*` in favor of `use nix::sys::ptrace` and then calling, for example, `ptrace::traceme()`
If you think the private functions could have better names, I'm all for it. You'll also need to re-name the tests (if you run Also, could you add this usage to the module documentation at the top? It'd be nice if we explicitly told people that's how they should do this versus just letting them figure it out. In theory they should know cause it's how a lot of Rust works, but it might be worth mentioning. What do you think? Too basic? |
I think I'll add the documentation in #666 |
test/sys/test_ptrace.rs
Outdated
@@ -1,6 +1,7 @@ | |||
use nix::Error; | |||
use nix::errno::*; | |||
use nix::unistd::*; | |||
use nix::sys::ptrace; | |||
use nix::sys::ptrace::*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change doesn't seem so useful if you still need to glob import a ton of things. Can we get rid of those here or does that make things really cluttered?
I can't find a better name for the private functions and I'd leave them as they are. A function called |
test/sys/test_ptrace.rs
Outdated
assert!(err == Error::Sys(Errno::EPERM) || err == Error::Sys(Errno::ENOSYS)); | ||
} | ||
|
||
// Just make sure ptrace_setoptions can be called at all, for now. | ||
#[test] | ||
fn test_ptrace_setoptions() { | ||
use nix::sys::ptrace::ptrace::*; // for PTRACE_O_TRACESYSGOOD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't you just importing the single constant here then? No need to bulk import. Same for PTRACE_ATTACH
above.
Man, we really need to get PtraceRequest
, PtraceEvent
, and PtraceOptions
into their own enums/bitflags. Having a ptrace
module within a ptrace
module is just horrible ergonomics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I probably was too tired back then ;) Sorry, I'll fix that tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I totally agree about the enums
Anything else needed to merge this? |
Yes, this needs a CHANGELOG entry (you should wait for #706 to land and rebase on that). |
This refactors the examples to more directly address the exact use cases for the `ioctl!` macro that `nix` provides. Additionally other macros that should not be used by end users are no longer discussed.
These are low-level functions that shouldn't be exposed
This also means that we need to properly mask off bits to the valid range of ioctl numbers.
These were exported for some weird reason and then left in for documentation. Also some parts of certain modules used them and others used the libc:: prefix. This was removed to improve the docs and also code consistency
There two different write semantics used with ioctls: one involves passing a pointer the other involves passing an int. Previously the ioctl! macro did not distinguish between these cases and left it up to the user to set the proper datatype. This previous version was not type safe and prone to errors. The solution here is to split the "write" variant into a "write_ptr" and "write_int" variant that makes the semantics more explicit and improves type safety by specifying arguments better.
Instead of relying on the macro user to calculate the length in bytes do that within the macro itself
ptsname(3) returns a pointer to a global variable, so it isn't thread-safe. Protect it with a mutex.
On semi-recent Rust versions (I think 1.8+) this now works properly.
It's just a (redundant) link to the repo, not a real homepage. According to the [API guidelines](https://github.com/brson/rust-api-guidelines#cargotoml-includes-all-common-metadata-c-metadata), this shouldn't be set in this case.
The recommended way to trace syscalls with ptrace is to set the PTRACE_O_TRACESYSGOOD option, to distinguish syscall stops from receiving an actual SIGTRAP. In C, this would cause WSTOPSIG to return SIGTRAP | 0x80, but nix wants to parse that as an actual signal. Add another wait status type for syscall stops (in the language of the ptrace(2) manpage, "PTRACE_EVENT stops" and "Syscall-stops" are different things), and mask out bit 0x80 from signals before trying to parse it. Closes nix-rust#550
Some tests were invoking non-async-signal-safe functions from the child process after a `fork`. Since they might be invoked in parallel, this could lead to problems.
Note that ptrace isn't documented as signal-safe, but it's supposed to just be a light syscall wrapper, so it should be fine.
When tests are run in QEMU the job just times out
These are assumed to be QEMU issues, as they also fail on mips.
Is it expected that rebasing on current master generated a big list of commits mentioned in the PR? (see the whole list after your comment) |
test/sys/test_wait.rs
Outdated
@@ -51,7 +51,8 @@ mod ptrace { | |||
use libc::_exit; | |||
|
|||
fn ptrace_child() -> ! { | |||
let _ = ptrace(PTRACE_TRACEME, Pid::from_raw(0), ptr::null_mut(), ptr::null_mut()); | |||
// TODO ptrace::traceme will be added in #666 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for these comments.
test/sys/test_wait.rs
Outdated
assert_eq!(waitpid(child, None), Ok(WaitStatus::PtraceSyscall(child))); | ||
// Then get the ptrace event for the process exiting | ||
assert!(ptrace(PTRACE_CONT, child, ptr::null_mut(), ptr::null_mut()).is_ok()); | ||
// TODO ptrace::cont will be added in #666 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
test/sys/test_wait.rs
Outdated
|
||
// First, stop on the next system call, which will be exit() | ||
assert!(ptrace(PTRACE_SYSCALL, child, ptr::null_mut(), ptr::null_mut()).is_ok()); | ||
// TODO ptrace::syscall will be added in #666 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
@@ -108,7 +108,7 @@ fn ptrace_other(request: ptrace::PtraceRequest, pid: Pid, addr: *mut c_void, dat | |||
} | |||
|
|||
/// Set options, as with `ptrace(PTRACE_SETOPTIONS,...)`. | |||
pub fn ptrace_setoptions(pid: Pid, options: ptrace::PtraceOptions) -> Result<()> { | |||
pub fn setoptions(pid: Pid, options: ptrace::PtraceOptions) -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no module-level documentation for the ptrace module, but it'd be good to add one showing an example usage that demonstrates the namespacing we recomment. We don't need it per-say, but it'd help users use this crate very easily. It'll also help us see where the imports aren't very ergonomic so we can improve them later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add the documentation when I'm done with all the ptrace changes, ok?
Besides, I really think about splitting up #666 into a couple smaller PRs because I'm starting to lose control of the tests.
Removed the comments. |
bors r+ |
692: Rename the public ptrace_* functions. r=Susurrus Unlike in C, we have namespacing in Rust. Renaming the functions allows us to avoid a `use nix::sys::ptrace::*` in favor of `use nix::sys::ptrace` and then calling, for example, `ptrace::traceme()` I'm wondering if we should rename the private functions too...
Build succeeded |
Unlike in C, we have namespacing in Rust. Renaming the functions allows us to avoid a
use nix::sys::ptrace::*
in favor ofuse nix::sys::ptrace
and then calling, for example,ptrace::traceme()
I'm wondering if we should rename the private functions too...