Re: inotify maintenance status

[Max Kellermann <max.kellermann@ionos.com>]

On Tue, Sep 19, 2023 at 12:59 PM Amir Goldstein <amir73il@gmail.com> wrote:
> Any API complexity can be hidden from users with userspace
> libraries. You can use the inotify-tools lib if you prefer.

That doesn't convince me at all, but that's a question of taste. We'll
just keep using inotify (with a patched kernel, which we have anyway).

> > 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'm not interested in this feature, I won't ever use it - all I
wanted is dfd support for inotify_add_watch()).

> 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.

I don't agree with your point that unnecessary complexity should be
mitigated by throwing more (library) code at it. That's just adding
more complexity and more overhead, the opposite of what I want.

Max