4 ms·

If you begin your comment with "Bah. This is complete nonsense." then you should at least address all of my points... Especially when you confirm one thing I'v

by fafner 12y ago

If you begin your comment with "Bah. This is complete nonsense." then you should at least address all of my points... Especially when you confirm one thing I've said in your first sentence. EVFILT_VNODE's design it too limited. It can watch directories (which after being opened are just a file descriptor). But it doesn't give you the information you need although they are available when the event is generated. The only explanation for this I can think of is because the API designers wanted to cover every event even if they didn't understand the particular use case. Which is exactly what's going to happen when you try to design an API in such a way. Yes, you could change kqueue and add another event type. But then why keep EVFILT_VNODE, except for legacy reasons? You complain about nonsense and then you compare a paper covering kqueue, which again is an API trying to do everything, to the documentation of inotify, which only covers a single class of events. And then you are disingenuous enough to only look at the README and not at the provided manpages and other material. inotify actually has pretty good documentation. But if you want to compare the 30 lines README to the kqueue paper ... well the kqueue paper covers EVFILT_VNODE with 19 lines, 7 of which simply list the possible actions. inotify is single purpose because it follows the "do one thing and do it right"-principle. The Linux folks had the freedom and time to come up with a good enough API because inotify wasn't forced into epoll, which itself follows the "do one thing and do it right"-principle. Meanwhile the kqueue designers came up with an fs notification API that is even inferior to what w32 offers...

teacup50 12y ago
Why do you keep ascribing EVFILT_VNODE's limitations to the the fact that the kqueue API is well designed and extensible? The inotify designers had 5 years to figure out the constraints and implications of file system notifications -- of course that gave them the opportunity to explore a different approach. Imagine that, instead of ignoring the hard problem of generic event APIs and NIH'ing a bad one-off hack, they'd adopted kqueue and extended it with an EVFILT_DIR? The whole industry would have benefited. Instead, they did the standard Linux thing of hacking together an incoherent bolt-on API because to do otherwise would require careful consideration and thought. Blaming the BSDs for not adopting Linux's hack is nonsense.
- fafner 12y ago
  I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible really means touching the kqueue API because that's the only way to extend it. On Linux epoll is far more extensible because it just means adding a new descriptor type. I don't know why you claim that Linux ignored the hard problem of generic event APIs. Unlike kqueue, Linux has a truly generic event API. That's what I've explaining since the beginning. Even if Linux had added kqueue and added an EVFILT_DIR then there would have been no guarantee that the BSD's would adopt the same API. There is no committee in charge of kqueue. The licenses are not portable and even if they'd agree on being compatible for kqueue then this would touch parts beyond it. And then there is the huge questions, why a directory and a file should be treated differently, when the only difference is the provided meta data. 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? Why didn't the BSDs do it? Claiming that inotify is a hack or incoherent is just beyond ridiculous. Inotify is far better than anything kqueue offers. So if anything then kqueue is a hack and badly thought out... If the BSD folks would simply adopt inotify then it would be one less painful thing to deal with when porting applications to BSD. All I hear nowadays is BSD folks complaining that the Linux folks are doing things differently and BSD has a hard time getting all the software to run they want. So adopting inotify would make it easier for the BSDs. In the end I don't care. But at least they should come up with a somewhat decent API. Doesn't matter if it's inotify or some NIH'ing.
  - teacup50 12y ago
    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.

by fafner 12y ago

teacup50 12y ago

Why do you keep ascribing EVFILT_VNODE's limitations to the the fact that the kqueue API is well designed and extensible? The inotify designers had 5 years to figure out the constraints and implications of file system notifications -- of course that gave them the opportunity to explore a different approach. Imagine that, instead of ignoring the hard problem of generic event APIs and NIH'ing a bad one-off hack, they'd adopted kqueue and extended it with an EVFILT_DIR? The whole industry would have benefited. Instead, they did the standard Linux thing of hacking together an incoherent bolt-on API because to do otherwise would require careful consideration and thought. Blaming the BSDs for not adopting Linux's hack is nonsense.

fafner 12y ago
I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible really means touching the kqueue API because that's the only way to extend it. On Linux epoll is far more extensible because it just means adding a new descriptor type. I don't know why you claim that Linux ignored the hard problem of generic event APIs. Unlike kqueue, Linux has a truly generic event API. That's what I've explaining since the beginning. Even if Linux had added kqueue and added an EVFILT_DIR then there would have been no guarantee that the BSD's would adopt the same API. There is no committee in charge of kqueue. The licenses are not portable and even if they'd agree on being compatible for kqueue then this would touch parts beyond it. And then there is the huge questions, why a directory and a file should be treated differently, when the only difference is the provided meta data. 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? Why didn't the BSDs do it? Claiming that inotify is a hack or incoherent is just beyond ridiculous. Inotify is far better than anything kqueue offers. So if anything then kqueue is a hack and badly thought out... If the BSD folks would simply adopt inotify then it would be one less painful thing to deal with when porting applications to BSD. All I hear nowadays is BSD folks complaining that the Linux folks are doing things differently and BSD has a hard time getting all the software to run they want. So adopting inotify would make it easier for the BSDs. In the end I don't care. But at least they should come up with a somewhat decent API. Doesn't matter if it's inotify or some NIH'ing.
- teacup50 12y ago
  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.