On Tue, Sep 19, 2023 at 4:11 PM Max Kellermann <max.kellermann@xxxxxxxxx> wrote: > > On Tue, Sep 19, 2023 at 3:01 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > We do not add new system calls for doing something that is already > > possible with existing system calls to make the life of a programmer > > easier - this has never been a valid argument for adding a new syscall. > > - it's not possible to safely add an inotify watch; this isn't about > making something easier, but about making something > safe/reliable/race-free in a way that wasn't possible before Yes, I meant it is possible to get the very similar functionality in a race-free way using fanotify. If fanotify does not meet your requirements please let us know in what way and perhaps fanotify could be improved. Using "inotify and not fanotity" is not a legit technical requirement. > - 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. If you think they were added to make the life of the programmer easier you did not understand them. Anyway, I've said my opinion about inotify_add_watch_at(). final call is up to Jan. Thanks, Amir. P.S. you may be able to provide magic /proc/self/$fd symlinks as path argument to inotify_add_watch() after opening them with O_PATH to get what you want - I didn't try.
