On Tue 19-09-23 13:21:56, Max Kellermann wrote: > On Tue, Sep 19, 2023 at 12:59 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > 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 guess no point in you wasting time for this. But if you'd try, I'll really find out it isn't so easy. Inotify event is fixed length so fsid+fhandle is completely out of the realm of "easy extension". If you wanted to return fd instead of wd, that would be doable with some kind of a flag in the mark mask, although it would be a bit inconsistent with the rest of the inotify API. > > 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. Well yes, fanotify could have been designed to make basic usage easier. But the design (some 15 years ago) was focusing more on filling in the functional gaps inotify had for usecases such as anti-virus monitors etc. and kind of left thinking about simple usecases for sometime later. So we have what we have. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
