public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Lyude Paul" <lyude@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<rust-for-linux@vger.kernel.org>, <nouveau@lists.freedesktop.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Gary Guo" <gary@garyguo.net>, "Benno Lossin" <lossin@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Janne Grunau" <j@jannau.net>
Subject: Re: [PATCH v7 6/7] rust: Introduce iosys_map bindings
Date: Mon, 09 Feb 2026 12:17:08 +0100	[thread overview]
Message-ID: <DGAE0M87A8X8.3OWL23XSZF7I6@kernel.org> (raw)
In-Reply-To: <20260206223431.693765-7-lyude@redhat.com>

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. :)

  reply	other threads:[~2026-02-09 11:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06 22:34 [PATCH v7 0/7] Rust bindings for gem shmem + iosys_map Lyude Paul
2026-02-06 22:34 ` [PATCH v7 1/7] rust: drm: gem: Add raw_dma_resv() function Lyude Paul
2026-02-09 12:40   ` Alice Ryhl
2026-02-09 12:47     ` Janne Grunau
2026-02-06 22:34 ` [PATCH v7 2/7] rust: helpers: Add bindings/wrappers for dma_resv_lock Lyude Paul
2026-02-06 22:34 ` [PATCH v7 3/7] rust: gem: Introduce DriverObject::Args Lyude Paul
2026-02-06 22:34 ` [PATCH v7 4/7] rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul
2026-02-17 19:38   ` Daniel Almeida
2026-02-06 22:34 ` [PATCH v7 5/7] rust: drm: gem: Introduce shmem::SGTable Lyude Paul
2026-02-17 19:53   ` Daniel Almeida
2026-02-06 22:34 ` [PATCH v7 6/7] rust: Introduce iosys_map bindings Lyude Paul
2026-02-09 11:17   ` Danilo Krummrich [this message]
2026-02-13  1:59   ` Deborah Brouwer
2026-03-04 22:59     ` lyude
2026-03-06 20:59       ` Deborah Brouwer
2026-02-06 22:34 ` [PATCH v7 7/7] rust: drm/gem: Add vmap functions to shmem bindings Lyude Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DGAE0M87A8X8.3OWL23XSZF7I6@kernel.org \
    --to=dakr@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=j@jannau.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rust-for-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox