Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 09 18:47
    cuviper opened #1210
  • Apr 09 10:18
    glebpom synchronize #1208
  • Apr 09 10:16
    glebpom synchronize #1208
  • Apr 08 18:57
    glebpom edited #1208
  • Apr 08 18:56
    glebpom edited #1208
  • Apr 08 15:55
    Artoria2e5 commented #349
  • Apr 08 15:41
    glebpom synchronize #1208
  • Apr 08 15:32
    glebpom opened #1209
  • Apr 08 14:41
    glebpom opened #1208
  • Apr 08 14:11
    glebpom synchronize #1206
  • Apr 08 07:30
    glebpom commented #1197
  • Apr 08 07:22
    glebpom synchronize #1206
  • Apr 08 07:19
    glebpom commented #1206
  • Apr 08 04:45
    bors[bot] closed #1195
  • Apr 08 04:45

    bors[bot] on master

    Update libc to 0.2.68 Handle open file descriptor loc… Update CHANGELOG and 12 more (compare)

  • Apr 08 04:45
    bors[bot] commented #1195
  • Apr 08 04:26

    bors[bot] on staging.tmp

    (compare)

  • Apr 08 04:26

    bors[bot] on staging

    Update libc to 0.2.68 Handle open file descriptor loc… Update CHANGELOG and 12 more (compare)

  • Apr 08 04:26

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Apr 08 04:26

    bors[bot] on staging.tmp

    Update libc to 0.2.68 Handle open file descriptor loc… Update CHANGELOG and 12 more (compare)

Aron Heinecke
@0xpr03
don't want to write another recursive algorithm ^^
Alan Somers
@asomers
You mean like ftw(3)?
Aron Heinecke
@0xpr03
uhm yes, thanks
Alan Somers
@asomers
I don't know. Did you check the standard library?
Aron Heinecke
@0xpr03
there is only read_dir but that's not recursive
Alan Somers
@asomers
Well I don't know then. Seems like somebody would've written one, but I don't think Nix includes one.
Aron Heinecke
@0xpr03
I'll try walkdir
Aron Heinecke
@0xpr03
oh, burntsushi crate.. welp I guess nix doesn't need that anymore ;)
Aron Heinecke
@0xpr03
I'm doing something wrong, I iterate over the directory and then update the group and permissions of every entry
but after some entries I reach ENOENT: No such file or directory
but there's no reason this would move away from "underneath" me
also the fchownat always passes but fchmodat will then always fail
LOL these are all broken links during tests...
Aron Heinecke
@0xpr03
aaaand NoFollowSymlink isn't implemented for fchmodat
so thats my curse..
Otavio Salvador
@otavio
@asomers I think the first part of the code seems good; I'd like to squash the code and rebase it on top of current tree. The iterator does not looks nice IMO ...
Otavio Salvador
@otavio
@asomers https://travis-ci.org/nix-rust/nix/jobs/580996478 sounds like related to #864?
Otavio Salvador
@otavio
@asomers ?!
Alan Somers
@asomers
Hello?
@otavio what's up?
Otavio Salvador
@otavio
@asomers I sent more fixes (including some rework of other methods which I will split on another PR when squashing) and I'd like a review
Alan Somers
@asomers
Ok. I saw your commits, but when there are that many, it looks like you're just fighting Travis. I can't tell which commits you actually want review on.
Otavio Salvador
@otavio
I think the Iterator needs more work
but I'd like a full review
the rest seems good IMO

So I would like to split it as:

  1. rework existing code
  2. add new from methods

The Iterator I'd like to check how we could improve it

Otavio Salvador
@otavio
@asomers nix-rust/nix#1127 I started to split out what is ready for merge.
So we reduce the PR and keep it focused.
nivpgir
@nivpgir

hi, I have the following function:

fn set_recording_mode(fd: RawFd, mode: u8) -> Result<i32, nix::Error>
{
    ioctl_readwrite!(set_request2, 0x5A, MCU_SET, McuOp);
    const SET_REC_MODE: u8 = 0xf4;
    let mut req : [u8;2] = [mode,0];
    let mut op = McuOp{r#type: SET_REC_MODE, len: 2, data: req.as_mut_ptr()};
    println!("{:?}", op);
    let ret = unsafe{ set_request2(fd, &mut op as *mut McuOp) };
    ret
}

which I'm calling in 2 different places in my code, with the same argument, and for some reason the first call succeeds and the second one fails, I ran it with strace and it looks like the ioctl call itself is the same:

~> time strace -e ioctl ./audio-test
McuOp { type: 244, len: 2, data: 0xffe78c7e }
ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x5a, 0x3, 0x80), 0xffe78c80) = 2
McuOp { type: 244, len: 2, data: 0xffe78c7e }
ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x5a, 0x3, 0x80), 0xffe78c80) = -1 EFAULT (Bad address)
thread 'main' panicked at 'Failed to set recording mode: Sys(EFAULT)', src/libcore/result.rs:999:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
+++ exited with 101 +++

another weird thing that I noticed is that if I add prints in various places then (depending on the location of the prints) even the first call can fail.
any chance someone here has run into something like this and can help me understand what I'm doing wrong?

the definition of the struct I'm passing is this:
#[repr(C)]
#[repr(align(128))]
#[derive(Debug)]
pub struct McuOp {
    r#type: u8 ,
    len: u32 ,
    data: *mut u8,
}
the alignment isn't supposed to be necessary, but it failed until I added it.
Alan Somers
@asomers
If I were you, I would use gdb (or rust-gdb), set a breakpoint on ioctl, and examine the data at the C level to see if it is really the same on both calls.
Mikail Bagishov
@MikailBag
Hello. Last nix release was published on 7th of June. Since that moment, approx. 25 PRs were merged. Do you mind publishing new release?
Of course, there is no hurry
I ask for release, because I have my project, which I'd like to publish on crates-io. Currently I have to depend on nix master.
Alan Somers
@asomers
That's an excellent reason to request a release. However, I'm traveling for the American holiday, so I won't be able to get to this for at least three more days. But I'll do it when I get home.
Alan Somers
@asomers
Just released 0.16.0
Alan Somers
@asomers
cc @MikailBag about the release
Mikail Bagishov
@MikailBag
Thank you!
James Babcock
@jimrandomh
Of the nix and libc crates, which is more likely to be maintained long term?
(I'm reimplementing some syscall-heavy C stuff in Rust, and am pretty sketched out by the libc crate. It doesn't have errno, and if there's an intended alternative, the documentation makes it incredibly hard to find. This sets an extremely low upper limit on how much battle testing that crate could have gotten.)
Alan Somers
@asomers
They are both highly likely to be maintained long term; just look at the download stats on crates.io.
libc is difficult to use directly. It basically exists to make it possible for somebody to make a crate like Nix.
James Babcock
@jimrandomh
Ehh, for my use case (transliterating C), using it directly seems straightforward, other than the errno thing
Alan Somers
@asomers
errno is weird because it's a global variable, not a function. See https://github.com/nix-rust/nix/blob/master/src/errno.rs for how to implement it.
Mikail Bagishov
@MikailBag
Why FsType's for different FSs are not exposed if target_env = musl ?
Alan Somers
@asomers
Because Musl doesn't define those constants.
pyroxymat
@pyroxymat
Hey @asomers is there any way to easily check which platforms IP_MULTICAST_ALL support? For instance I know Linux has the option, but I am not sure for NetBSD / android.
Alan Somers
@asomers
@pyroxymat You need to check in the libc crate. https://github.com/rust-lang/libc . Of course, it's possible that it's supported by some OSes but hasn't been added to libc yet. In that case, the best place to check is in online man pages