On Tue, Sep 19, 2023 at 3:51 PM Max Kellermann <max.kellermann@xxxxxxxxx> wrote: > > 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. > Both Jan and I already gave an answer to this specific patch. The answer was no. 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. Thanks, Amir.
