13 ms·

You're absolutely 100% full of crap. I already explained how kqueue's flexibility means that an EVFILT_DIR can be added easily, and work with all other event me

You're absolutely 100% full of crap. I already explained how kqueue's flexibility means that an EVFILT_DIR can be added easily, and work with all other event mechanisms on the system. > The Linux devs had 5 years to come up with the inotify design because their API is more flexible. That doesn't even begin to make sense. There's nothing inherent in the kqueue API that mandates that all filter types be defined upfront and never be extended or modified. > On Linux epoll is far more extensible because it just means adding a new descriptor type. How is that more extensible? The whole point of kqueue is that there exists a class of event types for which a read-based FD API is not the most efficient mechanism for event dispatch. > Apple apparently has added a completely different approach to fs notifications. Based on a device and a deamon. Why didn't they just add an EVFILT_DIR, if that's as easy as you claim? Corporate developer politics. The people working on kqueue and the people working on Spotlight (the primary FSEvent consumer) were in two separate universes. > Why didn't the BSDs do it? It clearly hasn't been a priority for anyone; kqueue meets most needs just fine.

fafner 12y ago
You are not helping your point by insulting me. I know that EVFILT_DIR can be added. I never disputed that. But it needs changes to the kqueue API. And apparently it is not so easy because nobody has done it and even operating systems using kqueue have opted to do it differently. You can talk all day about how things could be done theoretically. But that doesn't matter if reality looks so much different. Maybe you should ask yourself why EVFILT_VNODE was so poorly designed.
- teacup50 12y ago
  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.

fafner 12y ago

You are not helping your point by insulting me. I know that EVFILT_DIR can be added. I never disputed that. But it needs changes to the kqueue API. And apparently it is not so easy because nobody has done it and even operating systems using kqueue have opted to do it differently. You can talk all day about how things could be done theoretically. But that doesn't matter if reality looks so much different. Maybe you should ask yourself why EVFILT_VNODE was so poorly designed.

teacup50 12y ago
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.