On Tue, Sep 19, 2023 at 12:59 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Any API complexity can be hidden from users with userspace > libraries. You can use the inotify-tools lib if you prefer. That doesn't convince me at all, but that's a question of taste. We'll just keep using inotify (with a patched kernel, which we have anyway). > > Getting an already-opened file descriptor, or just the file_handle, is > > certainly an interesting fanotify feature. But that could have easily > > been added to inotify with a new "mask" flag for the > > inotify_add_watch() function. > > > > "could have easily been added" is not a statement that I am willing > to accept. Are you willing to take a bet? I come up with a patch for implementing this for inotify, let's say within a week, and you agree to merge it? (I'm not interested in this feature, I won't ever use it - all I wanted is dfd support for inotify_add_watch()). > The things that you are complaining about in the API are the exact > things that were needed to make the advanced features work. Not exactly - I complain that fanotify makes the complexity mandatory, the complexity is the baseline of the API. It would have been possible to design an API that is simple for 99% of all users, as simple as inotify; and only those who need the advanced features get the complexity as an option. I don't agree with your point that unnecessary complexity should be mitigated by throwing more (library) code at it. That's just adding more complexity and more overhead, the opposite of what I want. Max
