If by "changes to the kqueue" API you mean "adding a new filter type, as kqueue was designed to support", then how is the kqueue API poorly designed? Why should

If by "changes to the kqueue" API you mean "adding a new filter type, as kqueue was designed to support", then how is the kqueue API poorly designed? Why should the BSDs adopt a completely separate inotify hack? "100% full of crap" is an accurate assessment when you keep trotting out completely nonsense arguments as fact instead of actually engaging on the technical content; consider it my adopting of Linus' discussion style. Is there some specific problem that can't be solved within the confines of the existing kevent types and data structures? This seems pretty simple: - EVFILT_VNODE isn't poorly designed for the use-case of monitoring a file. - EVFILT_VNODE is poorly designed for the use-case of monitoring a directory hierarchy, but that isn't the intended use case. Nowhere have you demonstrated why the BSDs should drop kqueue in favor of Linux's hack; as for why it hasn't been implemented: because apparently no other kernel developers have needed it badly enough. Mac OS X FSEvents as a counter-example doesn't hold technical water; the reasons for FSEvents being separate from kqueue are solely to do with Apple's internal political machinations, and you've provided no technical analysis that demonstrate otherwise.