Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 09 Aug 2023 20:08:30 +0200
Message-ID: <87o7jgccm9.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Takashi Iwai <tiwai@suse.de>, Christoph Hellwig <hch@lst.de>,
        linux-kernel@vger.kernel.org,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mark Brown <broonie@kernel.org>, netdev@vger.kernel.org
Subject: Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer
In-Reply-To: <CAHk-=wh-mUL6mp4chAc6E_UjwpPLyCPRCJK+iB4ZMD2BqjwGHA@mail.gmail.com>
References: <87edkce118.wl-tiwai@suse.de>
        <20230809143801.GA693@lst.de>
        <CAHk-=wiyWOaPtOJ1PTdERswXV9m7W_UkPV-HE0kbpr48mbnrEA@mail.gmail.com>
        <87wmy4ciap.wl-tiwai@suse.de>
        <CAHk-=wh-mUL6mp4chAc6E_UjwpPLyCPRCJK+iB4ZMD2BqjwGHA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Wed, 09 Aug 2023 19:01:50 +0200,
Linus Torvalds wrote:
> 
> On Wed, 9 Aug 2023 at 09:05, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > OTOH, it simplifies the code well for us; as of now, we have two
> > callbacks for copying PCM memory from/to the device, distinct for
> > kernel and user pointers.  It's basically either copy_from_user() or
> > memcpy() of the given size depending on the caller.  The sockptr_t or
> > its variant would allow us to unify those to a single callback.
> 
> I didn't see the follow-up patches that use this, but...
> 
> > (And yeah, iov_iter is there, but it's definitely overkill for the
> > purpose.)
> 
> You can actually use a "simplified form" of iov_iter, and it's not all that bad.
> 
> If the actual copying operation is just a memcpy, you're all set: just
> do copy_to/from_iter(), and it's a really nice interface, and you
> don't have to carry "ptr+size" things around.
> 
> And we now have a simple way to generate simple iov_iter's, so
> *creating* the iter is trivial too:
> 
>         struct iov_iter iter;
>         int ret = import_ubuf(ITER_SRC/DEST, uptr, len, &iter);
> 
>         if (unlikely(ret < 0))
>                 return ret;
> 
> and you're all done. You can now pass '&iter' around, and it has a
> nice user pointer and a range in it, and copying that thing is easy.
> 
> Perhaps somewhat strangely (*) we don't have the same for a simple
> kernel buffer, but adding that wouldn't be hard. You either end up
> using a 'kvec', or we could even add something like ITER_KBUF if it
> really matters.
> 
> 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.
> 
> So yes, iov_iter does have some abstraction overhead, but it really
> isn't that bad. And it *does* allow you to do a lot of things, and can
> actually simplify the users quite a bit, exactly because it allows you
> to just pass that single iter pointer around, and you automatically
> have not just the user/kernel distinction, you have the buffer size,
> and you have a lot of helper functions to use it.
> 
> I really think that if you want a user-or-kernel buffer interface, you
> should use these things.
> 
> Please? At least look into it.

All sounds convincing, I'll take a look tomorrow.  Thanks!


Takashi

> 
>                  Linus
> 
> (*) Well, not so strange - we've just never needed it.
>