From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC4FFE7E0CA for ; Mon, 9 Feb 2026 11:17:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0C5BF10E0AC; Mon, 9 Feb 2026 11:17:15 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="VQRjsVLj"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79B9C10E0AC; Mon, 9 Feb 2026 11:17:13 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4A158444E9; Mon, 9 Feb 2026 11:17:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4607CC116C6; Mon, 9 Feb 2026 11:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770635832; bh=rkjWDYmA+Gv4imCPiiPARsynkjj0DK/cDi4XGUpA6Ms=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=VQRjsVLjLWT1MrF1DBlVdjjWR6ga2Wp+NvD/EvTo8QihVuxkXVa0xYQXZQf5ntODl aI4IQ1KP67cTrRkYwbZmUHlQ/m8i3A/TsTB8dKV6p2eGJu1ydQ+pa8xuU9wjG8DPVs qsB1f6jk4rJJpmaNFylLSsuTQCBA4fUeJ2NRd/zuAbjH2gaU6wNtY/1Xgg4qIB9A2q ROQiA1j//1vQK6AUMjJGKB0oLZYMbIDmj0OvKXRu4iKk3EOR2B02yGBFL3Xp8zgDgX cz6pjeA2TdjFpA8Fobu8O7w30a4wcxDCL+oHMcpB/9I4mM/8buOxn7hQUo4rM9749S ATD+qcWiAUaJw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 09 Feb 2026 12:17:08 +0100 Message-Id: Subject: Re: [PATCH v7 6/7] rust: Introduce iosys_map bindings Cc: , , , , "Daniel Almeida" , "Gary Guo" , "Benno Lossin" , "Alexandre Courbot" , "Janne Grunau" To: "Lyude Paul" From: "Danilo Krummrich" References: <20260206223431.693765-1-lyude@redhat.com> <20260206223431.693765-7-lyude@redhat.com> In-Reply-To: <20260206223431.693765-7-lyude@redhat.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri Feb 6, 2026 at 11:34 PM CET, Lyude Paul wrote: > +/// Raw unsized representation of a `struct iosys_map`. > +/// > +/// This struct is a transparent wrapper around `struct iosys_map`. The = C API does not provide the > +/// size of the mapping by default, and thus this type also does not inc= lude the size of the > +/// mapping. As such, it cannot be used for actually accessing the under= lying data pointed to by the > +/// mapping. > +/// > +/// With the exception of kernel crates which may provide their own wrap= pers around `RawIoSysMap`, > +/// users will typically not interact with this type directly. > +#[repr(transparent)] > +pub struct RawIoSysMap(bindings::iosys_map); I'm still against using struct iosys_map as a common frontend for I/O memor= y and system memory. Exposing this as another I/O backend instead of just having a Rust structur= e as frontend for a "real" abstraction around the Rust backends has various downsides. (1) We are limited to the features of struct iosys_map. The corresponding= Rust backends may provide additional functionality, which we can't access = with struct iosys_map. For instance, they Mmio will provide a relaxed() me= thod providing access to a borrowed backend providing relaxed ordering accessors. (2) We loose out on the capability to consider compile time checks regard= ing the guaranteed minimum size of the mapping. (To be fair this could be implemented on `IoSysMap` itself as well, but it would duplicate code= that we already have in the corresponding backends.) (3) You have to duplicate the safety requirements of the backends that st= ruct iosys_map wraps. In fact, this series ignores that if the backend is = I/O memory we have to guarantee the it is revoked when the device this I/= O memory originates from is unbound. Having a look at patch 7, it should be possible to read `is_iomem` and `vad= dr` / `vaddr_iomem` from the struct iosys_map and just construct the "real" `Mmio= ` backend from it. We also have to create a backend for normal system memory,= but that should be trivial. :)