[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yeklkcc7NXKYDHUL@sol.localdomain>
Date: Thu, 20 Jan 2022 01:04:17 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-xfs@...r.kernel.org, Dave Chinner <david@...morbit.com>,
"Darrick J . Wong" <djwong@...nel.org>,
Theodore Ts'o <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Satya Tangirala <satyat@...gle.com>
Subject: Re: [PATCH v10 1/5] fscrypt: add functions for direct I/O support
On Thu, Jan 20, 2022 at 12:27:45AM -0800, Christoph Hellwig wrote:
> > +/**
> > + * fscrypt_dio_unsupported() - check whether a DIO (direct I/O) request is
> > + * unsupported due to encryption constraints
> > + * @iocb: the file and position the I/O is targeting
> > + * @iter: the I/O data segment(s)
> > + *
> > + * Return: true if DIO is unsupported
> > + */
> > +bool fscrypt_dio_unsupported(struct kiocb *iocb, struct iov_iter *iter)
>
> I always find non-negated functions easier to follow, i.e. turn this
> into fscrypt_dio_supported().
>
I actually had changed this from v9 because fscrypt_dio_supported() seemed
backwards, given that its purpose is to check whether DIO is unsupported, not
whether it's supported per se (and the function's comment reflected this). What
ext4 and f2fs do is check a list of reasons why DIO would *not* be supported,
and if none apply, then it is supported. This is just one of those reasons.
This is subjective though, so if people prefer the old way, I'll change it back.
- Eric
Powered by blists - more mailing lists