Skip to content
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

Merged
merged 43 commits into from
Jul 25, 2017
Merged

Conversation

marmistrz
Copy link
Contributor

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...

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()`
@Susurrus
Copy link
Contributor

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 cargo test before pushing you'll generally save yourself some time with this PRs).

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?

@marmistrz
Copy link
Contributor Author

I think I'll add the documentation in #666

@@ -1,6 +1,7 @@
use nix::Error;
use nix::errno::*;
use nix::unistd::*;
use nix::sys::ptrace;
use nix::sys::ptrace::*;
Copy link
Contributor

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?

@marmistrz
Copy link
Contributor Author

I can't find a better name for the private functions and I'd leave them as they are. A function called other looks weird.

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
Copy link
Contributor

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.

Copy link
Contributor Author

@marmistrz marmistrz Jul 20, 2017

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.

Copy link
Contributor Author

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

@marmistrz
Copy link
Contributor Author

Anything else needed to merge this?

@Susurrus
Copy link
Contributor

Yes, this needs a CHANGELOG entry (you should wait for #706 to land and rebase on that).

Susurrus and others added 18 commits July 25, 2017 09:09
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.
jonas-schievink and others added 18 commits July 25, 2017 09:09
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.
@marmistrz
Copy link
Contributor Author

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)

@@ -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
Copy link
Contributor

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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.


// 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
Copy link
Contributor

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<()> {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@marmistrz
Copy link
Contributor Author

Removed the comments.

@Susurrus
Copy link
Contributor

bors r+

bors bot added a commit that referenced this pull request Jul 25, 2017
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...
@bors
Copy link
Contributor

bors bot commented Jul 25, 2017

@bors bors bot merged commit bf93180 into nix-rust:master Jul 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants