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

fcntl: adding macOs F_RDADVISE flag #2480

Merged
merged 3 commits into from
Sep 4, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion changelog/2113.added.md
Copy link
Member

Choose a reason for hiding this comment

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

This was accidentally modified, please revert it.

Original file line number Diff line number Diff line change
@@ -1 +1 @@
Add socket option `IPV6_PKTINFO` for BSDs/Linux/Android, also `IPV6_RECVPKTINFO` for DragonFlyBSD
Add socket option `IPV6_PKTINFO` for BSDs/Linux/Android, also `IPV6_RECVPKTINFO` for DragonFlyBSD
1 change: 1 addition & 0 deletions changelog/2480.added.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Add fcntl constant `F_RDADVISE` for Apple target
7 changes: 7 additions & 0 deletions src/fcntl.rs
Original file line number Diff line number Diff line change
Expand Up @@ -797,6 +797,9 @@ pub enum FcntlArg<'a> {
/// Return the full path without firmlinks of the fd.
#[cfg(apple_targets)]
F_GETPATH_NOFIRMLINK(&'a mut PathBuf),
/// Issue an advisory read async with no copy to user
#[cfg(apple_targets)]
F_RDADVISE(libc::radvisory),
Copy link
Member

Choose a reason for hiding this comment

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

I saw this was changed in the "testing" commit, the previous API is indeed a bit unclear:

F_RDADVISE(off_t, c_int),

I am actually thinking about this:

F_RDADVISE {
    offset: off_t,
    count: c_int,
}

So semantically, the API will be more clear and users won't need to bother with the libc raw structure. The drawback is, we need to copy these 2 numbers, considering they are simply numbers, IMHO, it is fine to copy them. Your thoughts? 🤔

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 was being consistent with flags passing libc::flock.

Copy link
Member

Choose a reason for hiding this comment

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

Get it, makes sense to me then:)

// TODO: Rest of flags
}

Expand Down Expand Up @@ -905,6 +908,10 @@ pub fn fcntl<Fd: std::os::fd::AsFd>(fd: Fd, arg: FcntlArg) -> Result<c_int> {
*path = PathBuf::from(OsString::from(optr.to_str().unwrap()));
return Ok(ok_res)
},
#[cfg(apple_targets)]
F_RDADVISE(rad) => {
libc::fcntl(fd, libc::F_RDADVISE, &rad)
}
}
};

Expand Down
20 changes: 20 additions & 0 deletions test/test_fcntl.rs
Original file line number Diff line number Diff line change
Expand Up @@ -732,3 +732,23 @@ mod test_flock {
.expect_err("Should not have been able to lock the file");
}
}

#[cfg(apple_targets)]
#[test]
fn test_f_rdadvise() {
use nix::fcntl::*;

let contents = vec![1; 1024];
let mut buf = [0; 1024];
let mut tmp = NamedTempFile::new().unwrap();
tmp.write_all(&contents).unwrap();
let fd = open(tmp.path(), OFlag::empty(), Mode::empty()).unwrap();
let rad = libc::radvisory {
ra_offset: 0,
ra_count: contents.len() as _,
};
let res = fcntl(&tmp, FcntlArg::F_RDADVISE(rad)).expect("rdadivse failed");
assert_ne!(res, -1);
assert_eq!(contents.len(), read(&fd, &mut buf).unwrap());
assert_eq!(contents, &buf[0..contents.len()]);
}