[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DGAE0M87A8X8.3OWL23XSZF7I6@kernel.org>
Date: Mon, 09 Feb 2026 12:17:08 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Lyude Paul" <lyude@...hat.com>
Cc: <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<rust-for-linux@...r.kernel.org>, <nouveau@...ts.freedesktop.org>, "Daniel
Almeida" <daniel.almeida@...labora.com>, "Gary Guo" <gary@...yguo.net>,
"Benno Lossin" <lossin@...nel.org>, "Alexandre Courbot"
<acourbot@...dia.com>, "Janne Grunau" <j@...nau.net>
Subject: Re: [PATCH v7 6/7] rust: Introduce iosys_map bindings
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 include the size of the
> +/// mapping. As such, it cannot be used for actually accessing the underlying data pointed to by the
> +/// mapping.
> +///
> +/// With the exception of kernel crates which may provide their own wrappers around `RawIoSysMap`,
> +/// users will typically not interact with this type directly.
> +#[repr(transparent)]
> +pub struct RawIoSysMap<const SIZE: usize = 0>(bindings::iosys_map);
I'm still against using struct iosys_map as a common frontend for I/O memory and
system memory.
Exposing this as another I/O backend instead of just having a Rust structure 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() method
providing access to a borrowed backend providing relaxed ordering
accessors.
(2) We loose out on the capability to consider compile time checks regarding
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 struct
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 `vaddr` /
`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. :)
Powered by blists - more mailing lists