Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
MIME-Version: 1.0
References: <20230918123217.932179-1-max.kellermann@ionos.com>
 <20230918123217.932179-3-max.kellermann@ionos.com> <20230918124050.hzbgpci42illkcec@quack3>
 <CAKPOu+-Nx_cvBZNox63R1ah76wQp6eH4RLah0O5mDaLo9h60ww@mail.gmail.com> <20230918142319.kvzc3lcpn5n2ty6g@quack3>
In-Reply-To: <20230918142319.kvzc3lcpn5n2ty6g@quack3>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Mon, 18 Sep 2023 18:28:49 +0300
Message-ID: <CAOQ4uxic7C5skHv4d+Gek_uokRL8sgUegTusiGkwAY4dSSADYQ@mail.gmail.com>
Subject: Re: [PATCH 3/4] inotify_user: add system call inotify_add_watch_at()
To:     Jan Kara <jack@suse.cz>
Cc:     Max Kellermann <max.kellermann@ionos.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Sep 18, 2023 at 5:23=E2=80=AFPM Jan Kara <jack@suse.cz> wrote:
>
> On Mon 18-09-23 15:57:43, Max Kellermann wrote:
> > On Mon, Sep 18, 2023 at 2:40=E2=80=AFPM Jan Kara <jack@suse.cz> wrote:
> > > Note that since kernel 5.13 you
> > > don't need CAP_SYS_ADMIN capability for fanotify functionality that i=
s
> > > more-or-less equivalent to what inotify provides.
> >
> > Oh, I missed that change - I remember fanotify as being inaccessible
> > for unprivileged processes, and fanotify being designed for things
> > like virus scanners. Indeed I should migrate my code to fanotify.
> >
> > If fanotify has now become the designated successor of inotify, that
> > should be hinted in the inotify manpage, and if inotify is effectively
> > feature-frozen, maybe that should be an extra status in the
> > MAINTAINERS file?
>
> The manpage update is a good idea. I'm not sure about the MAINTAINERS
> status - we do have 'Obsolete' but I'm reluctant to mark inotify as
> obsolete as it's perfectly fine for existing users, we fully maintain it
> and support it but we just don't want to extend the API anymore. Amir, wh=
at
> are your thoughts on this?

I think that the mention of inotify vs. fanotify features in fanotify.7 man=
 page
is decent - if anyone wants to improve it I won't mind.
A mention of fanotify as successor in inotify.7 man page is not a bad idea =
-
patches welcome.

As to MAINTAINERS, I think that 'Maintained' feels right.
We may consider 'Odd Fixes' for inotify and certainly for 'dnotify',
but that sounds a bit too harsh for the level of maintenance they get.

I'd like to point out that IMO, man-page is mainly aimed for the UAPI
users and MAINTAINERS is mostly aimed at bug reporters and drive-by
developers who submit small fixes.

When developers wish to add a feature/improvement to a subsystem,
they are advised to send an RFC with their intentions to the subsystem
maintainers/list to get feedback on their design before starting to impleme=
nt.
Otherwise, the feature could be NACKed for several reasons other than
"we would rather invest in the newer API".

Bottom line - I don't see a strong reason to change anything, but I also do
not object to improving man page nor to switching to 'Odd Fixes' status.

Thanks,
Amir.