On Tue, Sep 19, 2023 at 2:21 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Regarding inotify improvements, as I wrote, they will each be judged > technically, but the trend is towards phasing it out. Then please reconsider merging inotify_add_watch_at(). It is a rather trivial patch set, only exposing a user_path_at() parameter to use space, like many other new system calls did with other old-style system calls. Only the last patch, the one which adds the new system call ot all arch-specific tables, is an ugly one, but that's not a property of the new feature but a general property of how system calls are wired in Linux. My proposed system call adds real value to all those who are currently using inotify, allowing them to use inotify with a modern and safe and race-free syscall interface, eliminating the unsafe fchdir() dance to emulate it in userspace. The inotify interface is widely used and will be for a long time to come, while it is hard to find code which already uses fanotify. GitHub code search finds 438 occurences of fanotify_init() calls, 4.6k inotify_init1() calls and 6.9k inotify_init() calls. Given the added complexity of fanotify and the uselessness of most of fanotify's feature for most software (except for dfd support), it is extremely unlikely that a noticable fraction of those thousands of projects will ever migrate to fanotify. Even if inotify is considered a legacy API, it should be allowed to modernize it; and adding dfd support to system calls is really important. Max
