[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMGVM/BdgsjMSsIF@dread.disaster.area>
Date: Thu, 27 Jul 2023 07:50:43 +1000
From: Dave Chinner <david@...morbit.com>
To: Hao Xu <hao.xu@...ux.dev>
Cc: io-uring@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Dominique Martinet <asmadeus@...ewreck.org>,
Pavel Begunkov <asml.silence@...il.com>,
Christian Brauner <brauner@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Stefan Roesch <shr@...com>, Clay Harris <bugs@...ycon.org>,
"Darrick J . Wong" <djwong@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org, Wanpeng Li <wanpengli@...cent.com>
Subject: Re: [PATCH 1/7] iomap: merge iomap_seek_hole() and iomap_seek_data()
On Wed, Jul 26, 2023 at 06:25:57PM +0800, Hao Xu wrote:
> From: Hao Xu <howeyxu@...cent.com>
>
> The two functions share almost same code, merge them together.
> No functional change in this patch.
No, please don't. seek data and seek hole have subtly different
semantics and return values, and we've explicitly kept them separate
because it's much easier to maintain them as separate functions with
separate semantics than combine them into a single function with
lots of non-obvious conditional behaviour.
The fact that the new iomap_seek() API requires a boolean "SEEK_DATA
or SEEK_HOLE" field to indicate that the caller wants makes it clear
that this isn't actually an improvement over explicit
iomap_seek_data() and iomap_seek_hole() API calls.
-Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists