[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHk-=whyv0cs056T8TvY1f0nOf+Gsb6oRWetxt+LiFZUD4KQCw@mail.gmail.com>
Date: Fri, 22 Sep 2023 11:51:19 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Howells <dhowells@...hat.com>
Cc: Jens Axboe <axboe@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@....de>,
Christian Brauner <christian@...uner.io>,
David Laight <David.Laight@...lab.com>,
Matthew Wilcox <willy@...radead.org>,
Jeff Layton <jlayton@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
linux-mm@...ck.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 09/13] iov_iter: Add a kernel-type iterator-only
iteration function
On Fri, 22 Sept 2023 at 05:03, David Howells <dhowells@...hat.com> wrote:
>
> Add an iteration function that can only iterate over kernel internal-type
> iterators (ie. BVEC, KVEC, XARRAY) and not user-backed iterators (ie. UBUF
> and IOVEC). This allows for smaller iterators to be built when it is known
> the caller won't have a user-backed iterator.
This one is pretty ugly, and has no actual users.
Without even explaining why we'd care about this abomination, NAK.
If we actyually have some static knowledge of "this will only use
iterators X/Y/Z", then we should probably pass that in as a constant
bitmask to the thing, instead of this kind of "kernel only" special
case.
But even then, we'd want to have actual explicit use-cases, not a
hypothetical "if you have this situation here's this function".
Linus
Powered by blists - more mailing lists