[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiXUWPf6PySkmQXGG0vFPvCtKKX4Mwh5Wvsw1ZGjN2ggg@mail.gmail.com>
Date: Wed, 9 Aug 2023 10:21:26 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Mark Brown <broonie@...nel.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer
On Wed, 9 Aug 2023 at 10:01, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Right now the kernel buffer init is a *bit* more involved than the
> above ubuf case:
>
> struct iov_iter iter;
> struct kvec kvec = { kptr, len};
>
> iov_iter_kvec(&iter, ITER_SRC/DEST, &kvec, 1, len);
>
> and that's maybe a *bit* annoying, but we could maybe simplify this
> with some helper macros even without ITER_KBUF.
Looking at the diff that Christoph quoted, you possibly also want
strncpy_from_iov()
and honestly, that's a bit of an odd operation for the traditional
iov_iter use, but it certainly shouldn't be _hard_ to implement.
I'd probably initially implement it as a special case that only deals
with the "one single buffer" case (whether user space or kernel
space), since that would presumably be what you'd ever have, but
extending it to the generic case later if people actually need it
would not be problematic - those "iterate_and_advance()" macros in
lib/iovec.c are all about that horror.
Linus
Powered by blists - more mailing lists