From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20A2E63B3 for ; Fri, 11 Aug 2023 13:54:38 +0000 (UTC) Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACEE618F; Fri, 11 Aug 2023 06:54:37 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 71FAA21868; Fri, 11 Aug 2023 13:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1691762076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4qa8/BC1poqyiCNiUJJGsDqq/dAqZVtYPldavYVoO9M=; b=df+qtuFvTeIPDAbs1LvqqhmV2SxNtZ64nCIgIZmngTs/cvZT63uNe8r4asquFjiMgcc6qL 7Oy784yAd21icDEM6XM4iZbnOCEUtgWyLRTKOzI4tX2qtpME5YHZUJzvhzicm9WQqPWFhP 3//NdWUGWDPGIOkMbbEwLxDHFaYjtXg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1691762076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4qa8/BC1poqyiCNiUJJGsDqq/dAqZVtYPldavYVoO9M=; b=wjuPv17QcZxsjZpv/8Wi1frm7hU+fkBuiFcWsOeNeziQiDo6WPSxDyXS7K/TbzLOIE2LBW qIGm/VfqF8YPR3Bg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 0FC55138E2; Fri, 11 Aug 2023 13:54:36 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id D63hApw91mS4DgAAMHmgww (envelope-from ); Fri, 11 Aug 2023 13:54:36 +0000 Date: Fri, 11 Aug 2023 15:54:35 +0200 Message-ID: <87350psmzo.wl-tiwai@suse.de> From: Takashi Iwai To: Linus Torvalds Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, Andy Shevchenko , Mark Brown , netdev@vger.kernel.org Subject: Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer In-Reply-To: <87o7jgccm9.wl-tiwai@suse.de> References: <87edkce118.wl-tiwai@suse.de> <20230809143801.GA693@lst.de> <87wmy4ciap.wl-tiwai@suse.de> <87o7jgccm9.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Wed, 09 Aug 2023 20:08:30 +0200, Takashi Iwai wrote: > > On Wed, 09 Aug 2023 19:01:50 +0200, > Linus Torvalds wrote: > > > > On Wed, 9 Aug 2023 at 09:05, Takashi Iwai 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! FYI, I rewrote and tested patches, and it looks promising. The only missing piece in the upstream side was the export of import_ubuf(). Takashi