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