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

reuse definitions from libc #561

Merged
merged 3 commits into from
Jul 7, 2017
Merged

reuse definitions from libc #561

merged 3 commits into from
Jul 7, 2017

Conversation

Mic92
Copy link
Contributor

@Mic92 Mic92 commented Mar 25, 2017

No description provided.

@Mic92 Mic92 force-pushed the cleanup branch 3 times, most recently from 04b8a34 to 45653cc Compare March 25, 2017 17:00
}

pub fn statfs<P: ?Sized + NixPath>(path: &P, stat: &mut vfs::Statfs) -> Result<()> {
pub fn statfs<P: ?Sized + NixPath>(path: &P, stat: &mut libc::statfs) -> Result<()> {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This also requires a changelog entry then.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, please add it to this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

pub f_frsize: FragmentSize,
pub f_spare: [SwordType; 5],
}

pub const ADFS_SUPER_MAGIC : FsType = 0xadf5;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These definitions are also available in libc. Should I remove them?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, the goal is to get all FFI definitions into libc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@Susurrus
Copy link
Contributor

This looks pretty good to me. I think we need to resolve the re-exporting of constants and then I think this is good to merge.

@homu
Copy link
Contributor

homu commented Apr 15, 2017

☔ The latest upstream changes (presumably #536) made this pull request unmergeable. Please resolve the merge conflicts.

CHANGELOG.md Outdated
@@ -12,6 +12,9 @@ This project adheres to [Semantic Versioning](http://semver.org/).
### Changed
- Marked `sys::mman::{ mmap, munmap, madvise, munlock, msync }` as unsafe.
([#559](https://github.com/nix-rust/nix/pull/559))
- `nix::sys::statfs::{statfs,fstatfs}` uses statfs definition from `libc::statfs` instead of own type `nix::sys::Statfs`.
Also file system type constants like `nix::sys::statfs::ADFS_SUPER_MAGIC` were removed in favor of the libc aquivalent.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if it isn't nicer to re-export all relevant libc constants. It's a little weird in consuming code to have to import constants from libc to use with nix effectively. @posborne @fiveop Is there a consensus on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine ignoring these constants for now. Eventually I want to implement a wrapper type like this as I've done in #527 for libc::termios.

Could you fix the spelling of "equivalent" here?

Copy link
Contributor Author

@Mic92 Mic92 Jul 6, 2017

Choose a reason for hiding this comment

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

The API advertised here was incorrect anyway on all platforms but linux. All the magic constants are linux specific. BSD* and OS X uses string constants: https://www.freebsd.org/cgi/man.cgi?query=statfs&sektion=2

@Susurrus
Copy link
Contributor

Susurrus commented Jun 3, 2017

I'd like if instead of making people use libc types with nix, they'd use nix types directly. So I suggest we keep a StatFs type that is a re-export of libc::sys::statfs and use that in places. I don't want our users to have to use libc for anything and instead rely on nix types explicitly. Can you change this for the functions you modified?

@Mic92
Copy link
Contributor Author

Mic92 commented Jun 3, 2017

There is not feedback from the maintainers of this project. So I will not put effort into this.

@Susurrus
Copy link
Contributor

@Mic92 Are you saying you aren't interested in getting this merged?

@Mic92
Copy link
Contributor Author

Mic92 commented Jun 20, 2017

It has not highest priority for me at the moment. I could also drop the last commit and only get the others merged.

@Susurrus
Copy link
Contributor

That'd be great if you could rebase this and keep only the first 2 commits (be sure to add a CHANGELOG entry for the first commit).

Mode::from_bits(prev).expect("[BUG] umask returned invalid Mode")
}

pub fn stat<P: ?Sized + NixPath>(path: &P) -> Result<FileStat> {
let mut dst = unsafe { mem::uninitialized() };
let res = try!(path.with_nix_path(|cstr| {
unsafe {
ffi::stat(cstr.as_ptr(), &mut dst as *mut FileStat)
libc::stat(cstr.as_ptr(), &mut dst as *mut FileStat)
Copy link
Contributor

Choose a reason for hiding this comment

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

Please either pull the changes to use libc::stat/fstat into a separate commit or change the name of this commit as this doesn't just modify mknod/umask.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed the title.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 6, 2017

This needs that spelling fix and cleaning up that one commit, then this should be good to merge.

@Mic92 Mic92 force-pushed the cleanup branch 2 times, most recently from 5a7cd6a to bf82b22 Compare July 6, 2017 22:59
@Mic92
Copy link
Contributor Author

Mic92 commented Jul 6, 2017

here we go.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 7, 2017

Great, another little bit of cleanup. Thanks for fixing those commits too, I like a nice commit history!

bors r+

bors bot added a commit that referenced this pull request Jul 7, 2017
561: reuse definitions from libc r=Susurrus
@bors
Copy link
Contributor

bors bot commented Jul 7, 2017

Timed out

@Mic92
Copy link
Contributor Author

Mic92 commented Jul 7, 2017

@bors naughty bot.

@asomers
Copy link
Member

asomers commented Jul 7, 2017

Umlaut:1, Buildbot: 0

Buildbot 0.9.5 has a known problem when a commit's author contains non-ascii characters. That's the cause of the Bors timeout. I'm going to bypass Bors for this one.

@asomers asomers merged commit 45c1821 into nix-rust:master Jul 7, 2017
@Susurrus
Copy link
Contributor

Susurrus commented Jul 7, 2017

@asomers I'm amazed at how many bugs we've found in buildbot just using it for a brief amount of time. I would've thought most of this would have been ironed out. Anyways, is there a bug filed upstream for that so we could see a fix at somepoint?

@Mic92 Mic92 deleted the cleanup branch July 7, 2017 15:28
@Mic92
Copy link
Contributor Author

Mic92 commented Jul 7, 2017

And I thought jenkins is buggy. Umlauts is just the basic case given how many emojis are used in rust projects.

@asomers
Copy link
Member

asomers commented Jul 7, 2017

@Susurrus here's the upstream bug. It's already fixed, but I haven't upgraded our install yet. buildbot/buildbot#3078 . I think this is the only real bug we've found so far. Everything else has been a configuration error on my part. It's still frustrating that it's so hard to come up with a good configuration, and there isn't a template for "Travis Replacement", but we can't blame BuildBot's code for those other problems.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 7, 2017

@asomers Yeah, maybe that's something you can contribute to their docs in your copious spare time! ;-)

But I thought there was also the bug about PRs from branches named master?

@asomers
Copy link
Member

asomers commented Jul 7, 2017

@Susurrus I'm pretty sure that the bug about PRs from branches named master is also a configuration problem. See Issue #652 . I made a config change last night, and it looks like it's working now.

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.

4 participants