On Tue, Sep 19, 2023 at 3:22 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Yes, I meant it is possible to get the very similar functionality in > a race-free way using fanotify. That's not the same. We already agreed that fanotify still misses features that have been available in inotify since forever. Going fanotify requires a rewrite of large chunks of code. Rejecting trivial inotify improvements because people should be using fanotify doesn't make real-world users happy. > If fanotify does not meet your requirements please let us know > in what way and perhaps fanotify could be improved. - return a watch descriptor (like inotify) as a fixed-size lookup key - add an option so returned events contain the watch descriptor and path relative to it (like inotify), not just the directory entry name - allow unprivileged processes to use this new option instead of FAN_REPORT_FID Supporting this simplified API still makes fanotify harder to use than inotify, but retains fanotify's full power while minimizing its API churn for the 99% of users who were already happy with inotify's feature set. > > - there are many precedents of new system calls just to add dfd > > support (fchmodat, execveat, linkat, mkdirat, ....) > > - there are also a few new system calls that were added to make the > > life of a programmer easier even though the same was already possible > > with existing system calls (close_range, process_madvise, pidfd_getfd, > > mount_setattr, ...) > > All those new syscalls add new functionality/security/performance. So does inotify_add_watch_at(). On the other hand, fanotify reduces performance by adding complexity and overhead - more system calls necessary, increased lookup overhead due to variable-length keys instead of 32-bit integers. > If you think they were added to make the life of the programmer easier > you did not understand them. Oh please. Don't be so arrogant.
