Add freebsd_inotify feature to use inotify on FreeBSD 14.4+#919
Draft
kev009 wants to merge 1 commit into
Draft
Conversation
FreeBSD 14.4+ provides an in-kernel inotify(2) implementation and libc
wrappers in libc.so.7. Switching FreeBSD's notify backend from kqueue
to inotify is a large win on big trees because kqueue requires one open
file descriptor per watched directory (or file) while inotify uses a
single fd with watch descriptors, scaling to large repositories without
hitting RLIMIT_NOFILE / kern.maxfiles_per_proc.
Add a `freebsd_inotify` cargo feature (default off). When enabled:
* `RecommendedWatcher` resolves to `INotifyWatcher` on FreeBSD.
* The `inotify` module compiles in (it uses only std::os::unix +
libc fcntl flags, no Linux-specific syscalls).
* The `inotify` crate is pulled in via an optional FreeBSD target dep,
and `inotify-sys/freebsd-native` is forwarded to skip linking the
userspace libinotify shim.
* The `BoundSender` / `bounded` helpers used by the inotify backend
are extended to compile under this cfg path.
When the feature is off, FreeBSD continues to use the kqueue backend, so
this is a strict opt-in and pre-14.4 FreeBSD remains buildable.
Two existing inotify-backend tests encoded Linux-specific event
semantics; both are adjusted here so the test suite is green on FreeBSD:
* `set_file_mtime` widened from `modify_data_any()` to `modify()`.
Linux's inotify reports utimensat(2) as IN_MODIFY (Data); FreeBSD's
reports it as IN_ATTRIB (Metadata), matching inotify(7)'s own
description (which lists timestamps under IN_ATTRIB). Both still
satisfy the portable contract "mtime change fires a Modify event".
* `write_to_a_hardlink_…doesnt_trigger…` gated to
#[cfg(target_os = "linux")] and renamed with an `_on_linux` suffix.
Linux's inotify is dirent-centric (events fire on the pathname used
for the write); FreeBSD's is inode-centric (events fire on every
pathname pointing to the modified inode). The test as written
encodes Linux's behavior; a comment documents the underlying
architectural difference.
Tested on FreeBSD: cargo test --workspace --features
notify/freebsd_inotify reports 74 passed, 0 failed, 2 ignored in
`notify` lib unittests, with all other workspace crates fully green.
Linux behavior is unchanged.
Author
|
Marked as a draft for now, this needs stable releases of hannobraun/inotify-rs#258 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
FreeBSD 14.4+ provides an in-kernel inotify(2) implementation and libc wrappers in libc.so.7. Switching FreeBSD's notify backend from kqueue to inotify is a large win on big trees because kqueue requires one open file descriptor per watched directory (or file) while inotify uses a single fd with watch descriptors, scaling to large repositories without hitting RLIMIT_NOFILE / kern.maxfiles_per_proc.
Add a
freebsd_inotifycargo feature (default off). When enabled:RecommendedWatcherresolves toINotifyWatcheron FreeBSD.inotifymodule compiles in (it uses only std::os::unix + libc fcntl flags, no Linux-specific syscalls).inotifycrate is pulled in via an optional FreeBSD target dep, andinotify-sys/freebsd-nativeis forwarded to skip linking the userspace libinotify shim.BoundSender/boundedhelpers used by the inotify backend are extended to compile under this cfg path.When the feature is off, FreeBSD continues to use the kqueue backend, so this is a strict opt-in and pre-14.4 FreeBSD remains buildable.
Two existing inotify-backend tests encoded Linux-specific event semantics; both are adjusted here so the test suite is green on FreeBSD:
set_file_mtimewidened frommodify_data_any()tomodify(). Linux's inotify reports utimensat(2) as IN_MODIFY (Data); FreeBSD's reports it as IN_ATTRIB (Metadata), matching inotify(7)'s own description (which lists timestamps under IN_ATTRIB). Both still satisfy the portable contract "mtime change fires a Modify event".write_to_a_hardlink_…doesnt_trigger…gated to #[cfg(target_os = "linux")] and renamed with an_on_linuxsuffix. Linux's inotify is dirent-centric (events fire on the pathname used for the write); FreeBSD's is inode-centric (events fire on every pathname pointing to the modified inode). The test as written encodes Linux's behavior; a comment documents the underlying architectural difference.Tested on FreeBSD: cargo test --workspace --features notify/freebsd_inotify reports 74 passed, 0 failed, 2 ignored in
notifylib unittests, with all other workspace crates fully green. Linux behavior is unchanged.Related Issues