In D50315#1158082, @markj wrote:

Per what I wrote above, I believe the native implementation would still be used, but the application would be compiled against libinotify inotify.h.

Yep, I messed up and it was still using libinotify's libinotify.h. I've redone the test properly and found that the program starts behaving differently if linked to libinotify.

In D50315#1158075, @markj wrote:

What if it is still using libinotify's libinotify.h?

In D50315#1157710, @markj wrote:

Yes, that was my intent in the previous revision, but I missed some flags. The new version should be almost completely compatible: the difference is with IN_CLOEXEC and IN_NONBLOCK, and the libinotify flag values are handled in libc. I think this provides compatibility in both directions, since libinotify already handles FreeBSD O_CLOEXEC and O_NONBLOCK as well.

Would it be possible to make native sys/inotify.h be a drop-in replacement for libinotify's one? In other words, I want a program that was compiled against /usr/include/sys/inotify.h to work when run with LD_PRELOAD=libinotify.so. This will provide an almost painless transition from libinotify to the native implementation.

In D50518#1156214, @kiwi wrote:

The change seems ok, I am surprised I didn't see any problems in my deployments or poudriere. Was a bug reported on Bugzilla for this ?

In D50315#1156202, @markj wrote:

There is also this:

40 /* libinotify-specific - Direct mode operation. See below. */                                                                                                                                                                                                                                                             
41 #define IN_DIRECT       0x80000000

Does anything use it?

Why was this abandoned?

Ping.

Ugh, I guess you're right. So we need to make sure that no libinotify-kqueue is installed on a native intofy-enabled system.

Now we need to figure how to handle a conflict with libinotify-kqueue. The problem can be observed with taking the main branch of Ports and running

Yes, works for me too now and the performance is on par with other implementations.

Qt tests now pass for me too.

Thanks. The latest upload fixes those tests for me, all 8 pass.

I pushed changes that allow testing glib's file monitoring: https://github.com/arrowd/freebsd-ports/tree/inotify-test

In D50315#1150050, @markj wrote:

Do you know offhand if there is much use for fanotify() compatibility? I'm wondering how widely used it is vs. inotify.

In D50315#1149915, @markj wrote:

From my reading of Linux inotify docs, IN_ACCESS should only be generated for objects within a watched directory, not for the watched directory itself. So, this test seems to contradict the documentation, and my implementation follows the documentation here. Which one is right? I don't have quick access to a Linux system to test.

I patched libinotify-kqueue to call into the native implementation and then ran its tests. Some of them are failing, here's the log

Hmm, does a clean build work?

I tried building it with make buildworld && make buildkernel and it failed with

--- libsys.so.7.full ---
Building shared library libsys.so.7
...
ld: error: version script assignment of 'FBSDprivate_1.0' to symbol '_inotify_add_watch' failed: symbol not defined
ld: error: version script assignment of 'FBSDprivate_1.0' to symbol '__sys_inotify_add_watch' failed: symbol not defined
ld: error: version script assignment of 'FBSDprivate_1.0' to symbol '_inotify_rm_watch' failed: symbol not defined
ld: error: version script assignment of 'FBSDprivate_1.0' to symbol '__sys_inotify_rm_watch' failed: symbol not defined
cc: error: linker command failed with exit code 1 (use -v to see invocation)