fcntl adding few apple extensions

[devnexen]

No description provided.

[SteveLauC]

Does Apple have any documentation on these two flags? They are quite new and thus not included in this online man page

[devnexen]

There is this

F_GETPATH_NOFIRMLINK Get the non firmlinked path of the file descriptor fildes. The argument must be a buffer of size MAXPATHLEN or greater.

Concretally the difference with the regular F_GETPATH is the path contains in addition the mount point.

F_BARRIERFSYNC Does the same thing as fsync(2) then issues a barrier command to the drive (arg is ignored). The barrier applies to I/O that have been flushed with fsync(2) on the same device before. These operations are guaranteed to be persisted before any other I/O that would follow the barrier, although no assumption should be made on what has been persisted or not when this call returns. After the barrier has been issued, operations on other FDs that have been fsync'd before can still be re-ordered by the device, but not after the barrier. This is typically useful to guarantee valid state on disk when ordering is a concern but durability is not. A barrier can be used to order two phases of operations on a set of file descriptors and ensure that no file can possibly get persisted with the effect of the second phase without the effect of the first one. To do so, execute operations of phase one, then fsync(2) each FD and issue a single barrier. Finally execute operations of phase two. This is currently implemented on HFS and APFS. It requires hardware support, which Apple SSDs are guaranteed to provide.

[SteveLauC]

Search the documents you provided, then I found this: fcntl(2) Xcode Man Pages

A few days ago, I went to an Apple Store, tried man 2 fcntl on its demo machine, and got nothing, seems that Apple is not interested in adding documents for the new stuff except for its own toolchain (e.g., Xcode)

[devnexen]

Search the documents you provided, then I found this: fcntl(2) Xcode Man Pages

A few days ago, I went to an Apple Store, tried man 2 fcntl on its demo machine, and got nothing, seems that Apple is not interested in adding documents for the new stuff except for its own toolchain (e.g., Xcode)

even for more historic features, some are documented only in the C'headers and sometimes in a obscure way. Fortunately, experiences shared across open source projects and reading macos's libc source help to understand better overtime.

[SteveLauC]

There are some merge conflicts that need to be resolved.

I think F_GETPATH_NOFIRMLINK deserves a unit test, any idea on how we can test it?

From this post, the path /home (on system volume) is a firmlink to /System/Volumes/Data/home (on date volume), if we open /home, then call fcntl(F_GETPATH_NOFIRMLINK) on it, /home instead of /System/Volumes/Data/home should be returned

[SteveLauC]

Well, CI failure is not your fault

Friendly ping @asomers, is there anything we can do about this:

⚠️ Failed to start an instance: FAILED_PRECONDITION: Monthly free compute limit exceeded!

[asomers]

⚠️ Failed to start an instance: FAILED_PRECONDITION: Monthly free compute limit exceeded!

Damn! Last month was the first that Cirrus has been limiting open source projects' compute hours. I made some changes to our CI configuration to reduce the load (#2101), and that worked for September. But now that @SteveLauC joined we're getting a lot more done. I guess it's your fault, Steve 😉 . In the short term, I think our only options are to pony up some cash or else wait for November. Currently, we're burning through about $250 worth of compute time per month (including $50 free for OSS), though that will probably decline as we work through the backlog. Longer term, we can probably economize our CI pipeline even further:

• Maybe reduce the QEMU builds?
• Set up some precommit scripting to take care of stuff like rustfmt?
• Move the OSX/arm64 and Linux/x86_64 builds into Github Pipelines, leaving FreeBSD/x86_64 and Linux/arm64 on Cirrus?
• Shut off github merge queues? They don't work exactly like bors. With bors, batching PRs together could reduce your CI load. With github merge queues, it seems to increase it.
• Merge chore: use towncrier for CHANGELOG #2149 . By reducing merge conflicts, that should also reduce our CI builds.

https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/
https://cirrus-ci.com/settings/github/nix-rust

[asomers]

I've paid for a few credits and restarted the CI for this PR. I'll open a new issue for longer term solutions.

[SteveLauC]

Friendly ping @devnexen, we have changed our changelog mode in #2149, please see CONTRIBUTING.md on how to add change logs