From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4F2C8111BF; Sat, 23 Aug 2025 13:57:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755957444; cv=none; b=NLYQ+LJStAlP1UG8v4Lbo3QUCDOJq1E3eO61VZjLjDpwOyE/S9deuRQl0iwLEjUFIRKr4qY/AggpjucIrjQP8Ybc39sxig6i0MQXW9x1NwhNPXd6QFvQGDSHZ6RtNxBmWe/4zsoyUSLbYSKvewONnWxeKuo/hZL9wwfS4KSbI9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755957444; c=relaxed/simple; bh=WEYZMYvb3E7pRkxiRNIRiagqsZ+9wO8HnO5/w0JGG4o=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=FsKZ90AqqxS4/YPvIOAO9kN56JM/Wsup2ZHBjpKZS7FocVLHse1DViF41hvU1BbDE/XvkXOFA2rmkds4/DCBRkGkQw0j+gULhn6bWArMKXhKB68xfgdSpFfS10VhADOgALUsuJ0SR6T5I6Z2TgGbpBtXtrmEHko3Pj1MHqLA1Z0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d6tQsC0p; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d6tQsC0p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FF3CC4CEE7; Sat, 23 Aug 2025 13:57:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755957443; bh=WEYZMYvb3E7pRkxiRNIRiagqsZ+9wO8HnO5/w0JGG4o=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=d6tQsC0p4guuZ93dC9NzAMbkc+7z65pV/C71qcORQB8nxe4l6r16hRL0U8uLy+Zia zbCO1x0oOEZ/cpivEacIdJnxYDcyqGfUw892dAxXvktveSLpCefymSPO3RxtCXlhDw GDxRMPTpBqZViNXTGVLSefm7Pg+/vOJpv3Ma3pKSpx4ii8jVHvQkcWjwrY+bVKY/t8 nNQ833ivnAHCCFKptfz4Y69tHUwDnbxmr8WnLqYAjJza/mMJ02vqw5HJWkSBPmC4G8 a9i2OiQzj1E7CKtEfKNal7um2JqSZaleFMB70ikDCLDGOH88d5rF11zHIaBQqLojpg 7Bz106prap5JA== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 23 Aug 2025 15:57:18 +0200 Message-Id: Cc: , , , , , , , , , , , , , , , , To: "Alexandre Courbot" From: "Danilo Krummrich" Subject: Re: [PATCH v2 3/5] rust: scatterlist: Add type-state abstraction for sg_table References: <20250820165431.170195-1-dakr@kernel.org> <20250820165431.170195-4-dakr@kernel.org> In-Reply-To: On Sat Aug 23, 2025 at 3:47 PM CEST, Alexandre Courbot wrote: > Oops, forgot to mention a couple more things: > > On Thu Aug 21, 2025 at 1:52 AM JST, Danilo Krummrich wrote: >> Add a safe Rust abstraction for the kernel's scatter-gather list >> facilities (`struct scatterlist` and `struct sg_table`). >> >> This commit introduces `SGTable`, a wrapper that uses a type-state >> pattern to provide compile-time guarantees about ownership and lifetime. > > Is this actually a typestate? From my understanding, the typestate > pattern implies transitions from one state to the other (such as > Unmapped -> Mapped), but in this version there are no such transitions > (the previous ones had, though). We are just using a generic parameter, > so mentioning typestate sounds a bit misleading to me. I'd argue that it's still kind of a typestate. You can derive &SGTable (i.e= . &SGTable) from SGTabe. So, technically there is an uni-directional transition I guess. > Another random thought, in the owned case, do we want to provide an > accessor to the provider of the backing pages? Or do we expect the > caller to take dispositions to keep such a reference if they need to > access the backing buffer post-mapping? That's not going to work that easily. Once the backing pages are DMA mapped= , the backing buffer can be accessed safely an more. See also the safety requirements of dma::CoherentAllocation::as_slice() and dma::CoherentAllocation::as_slice_mut(). If we want to support that, we have to provide a new type for this and mayb= e want to define a common trait for DMA mapped memory accessors, etc. Not the scope for this series, I believe. :)