[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxgL1p2P1e2AkHLHiicKXa9cwrFNkHy-oXsdGKA9EkDb6g@mail.gmail.com>
Date: Thu, 21 Nov 2024 12:04:23 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Jan Kara <jack@...e.cz>, Josef Bacik <josef@...icpanda.com>, kernel-team@...com,
linux-fsdevel@...r.kernel.org, torvalds@...ux-foundation.org,
viro@...iv.linux.org.uk, linux-xfs@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v8 02/19] fsnotify: opt-in for permission events at file
open time
On Thu, Nov 21, 2024 at 11:09 AM Christian Brauner <brauner@...nel.org> wrote:
>
> > It is not that I object to "two bit constants". FMODE_FSNOTIFY_MASK is a
> > two-bit constant and a good one. But the name clearly suggests it is not a
> > single bit constant. When you have all FMODE_FOO and FMODE_BAR things
> > single bit except for FMODE_BAZ which is multi-bit, then this is IMHO a
> > recipe for problems and I rather prefer explicitely spelling the
> > combination out as FMODE_NONOTIFY | FMODE_NONOTIFY_PERM in the few places
> > that need this instead of hiding it behind some other name.
>
> Very much agreed!
Yes, I agree as well.
What I meant is that the code that does
return FMODE_NONOTIFY | FMODE_NONOTIFY_PERM;
is going to be unclear to the future code reviewer unless there is
a comment above explaining that this is a special flag combination
to specify "suppress only pre-content events".
Thanks,
Amir.
Powered by blists - more mailing lists