From: Matthew Auld <matthew.auld@intel.com>
To: Joel Fernandes <joelagnelf@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
dri-devel@lists.freedesktop.org, dakr@kernel.org,
David Airlie <airlied@gmail.com>
Cc: acourbot@nvidia.com, Alistair Popple <apopple@nvidia.com>,
Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
joel@joelfernandes.org, Elle Rhumsaa <elle@weathered-steel.dev>,
Daniel Almeida <daniel.almeida@collabora.com>,
Andrea Righi <arighi@nvidia.com>,
Philipp Stanner <phasta@kernel.org>,
nouveau@lists.freedesktop.org
Subject: Re: [PATCH RFC 4/4] samples: rust: Add sample demonstrating DRM buddy allocator
Date: Fri, 31 Oct 2025 16:42:22 +0000 [thread overview]
Message-ID: <79bbbd8b-e60b-435b-82b6-ea59230997e2@intel.com> (raw)
In-Reply-To: <20251030190613.1224287-5-joelagnelf@nvidia.com>
On 30/10/2025 19:06, Joel Fernandes wrote:
> Demonstrates usage of the DRM buddy allocator bindings through
> a simple test module that initializes the allocator, performs
> allocations, and prints information about the allocated blocks.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> samples/rust/Kconfig | 14 +++++
> samples/rust/Makefile | 1 +
> samples/rust/rust_drm_buddy.rs | 106 +++++++++++++++++++++++++++++++++
> 3 files changed, 121 insertions(+)
> create mode 100644 samples/rust/rust_drm_buddy.rs
>
> diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
> index b45631e2593c..8ccb4064ba91 100644
> --- a/samples/rust/Kconfig
> +++ b/samples/rust/Kconfig
> @@ -21,6 +21,20 @@ config SAMPLE_RUST_CLIST
>
> If unsure, say N.
>
> +config SAMPLE_RUST_DRM_BUDDY
> + tristate "DRM buddy allocator sample"
> + depends on DRM_BUDDY
> + help
> + This option builds the Rust DRM buddy allocator sample.
> +
> + The sample demonstrates using the DRM buddy allocator bindings
> + to allocate and free memory blocks.
> +
> + To compile this as a module, choose M here:
> + the module will be called rust_drm_buddy.
> +
> + If unsure, say N.
> +
> config SAMPLE_RUST_CONFIGFS
> tristate "Configfs sample"
> depends on CONFIGFS_FS
> diff --git a/samples/rust/Makefile b/samples/rust/Makefile
> index f8899c0df762..a56204ee4e96 100644
> --- a/samples/rust/Makefile
> +++ b/samples/rust/Makefile
> @@ -2,6 +2,7 @@
> ccflags-y += -I$(src) # needed for trace events
>
> obj-$(CONFIG_SAMPLE_RUST_CLIST) += rust_clist.o
> +obj-$(CONFIG_SAMPLE_RUST_DRM_BUDDY) += rust_drm_buddy.o
> obj-$(CONFIG_SAMPLE_RUST_MINIMAL) += rust_minimal.o
> obj-$(CONFIG_SAMPLE_RUST_MISC_DEVICE) += rust_misc_device.o
> obj-$(CONFIG_SAMPLE_RUST_PRINT) += rust_print.o
> diff --git a/samples/rust/rust_drm_buddy.rs b/samples/rust/rust_drm_buddy.rs
> new file mode 100644
> index 000000000000..96907bc19243
> --- /dev/null
> +++ b/samples/rust/rust_drm_buddy.rs
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Rust DRM buddy allocator sample.
> +//!
> +//! This sample demonstrates using the DRM buddy allocator from Rust.
> +
> +use kernel::{
> + drm::buddy::{
> + BuddyFlags,
> + DrmBuddy, //
> + },
> + prelude::*,
> + sizes::*, //
> +};
> +
> +module! {
> + type: RustDrmBuddySample,
> + name: "rust_drm_buddy",
> + authors: ["Joel Fernandes"],
> + description: "DRM buddy allocator sample",
> + license: "GPL",
> +}
> +
> +struct RustDrmBuddySample;
> +
> +impl kernel::Module for RustDrmBuddySample {
> + fn init(_module: &'static ThisModule) -> Result<Self> {
> + // Create a buddy allocator managing 1GB with 4KB chunks.
> + let buddy = DrmBuddy::new(SZ_1G, SZ_4K)?;
> +
> + pr_info!("=== Test 1: Single 16MB block ===\n");
> + let allocated = buddy.alloc_blocks(
> + 0,
> + 0,
Does this map to the start/end? Surprised that this works with
RANGE_ALLOCATION below. I guess it works because of the end-1, but I'm
not sure if that was intended.
Anyway, probably you didn't really want RANGE_ALLOCATION here? That is
only if you want something at a specific offset or within a special bias
range. So here I think it will give you a massive bias range covering
everything due to end-1, but all you wanted was any available 16M block,
which is the typical flow? It still technically works, but looks a bit
non-standard and will internally take the bias range path, which is not
ideal :)
Also I guess worth updating the example in buddy.rs, which also does this?
> + SZ_16M,
> + SZ_4K,
> + BuddyFlags::RANGE_ALLOCATION,
> + GFP_KERNEL,
> + )?;
> +
> + let mut count = 0;
> + for block in &allocated {
> + pr_info!(
> + " Block {}: offset=0x{:x}, order={}, size={}\n",
> + count,
> + block.offset(),
> + block.order(),
> + block.size(&buddy)
> + );
> + count += 1;
> + }
> + pr_info!(" Total: {} blocks\n", count);
> + drop(allocated);
> +
> + pr_info!("=== Test 2: Three 4MB blocks ===\n");
> + let allocated = buddy.alloc_blocks(
> + 0,
> + 0,
> + SZ_4M * 3,
> + SZ_4K,
> + BuddyFlags::RANGE_ALLOCATION,
> + GFP_KERNEL,
> + )?;
> +
> + count = 0;
> + for block in &allocated {
> + pr_info!(
> + " Block {}: offset=0x{:x}, order={}, size={}\n",
> + count,
> + block.offset(),
> + block.order(),
> + block.size(&buddy)
> + );
> + count += 1;
> + }
> + pr_info!(" Total: {} blocks\n", count);
> + drop(allocated);
> +
> + pr_info!("=== Test 3: Two 8MB blocks ===\n");
> + let allocated = buddy.alloc_blocks(
> + 0,
> + 0,
> + SZ_8M * 2,
> + SZ_4K,
> + BuddyFlags::RANGE_ALLOCATION,
> + GFP_KERNEL,
> + )?;
> +
> + count = 0;
> + for block in &allocated {
> + pr_info!(
> + " Block {}: offset=0x{:x}, order={}, size={}\n",
> + count,
> + block.offset(),
> + block.order(),
> + block.size(&buddy)
> + );
> + count += 1;
> + }
> + pr_info!(" Total: {} blocks\n", count);
> +
> + pr_info!("=== All tests passed! ===\n");
> +
> + Ok(RustDrmBuddySample {})
> + }
> +}
next prev parent reply other threads:[~2025-10-31 16:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 19:06 [PATCH RFC 0/4] rust: Introduce support for C linked list interfacing and DRM Buddy bindings Joel Fernandes
2025-10-30 19:06 ` [PATCH RFC 1/4] rust: clist: Add abstraction for iterating over C linked lists Joel Fernandes
2025-10-30 21:15 ` Danilo Krummrich
2025-10-30 22:44 ` Joel Fernandes
2025-11-01 3:51 ` Alexandre Courbot
2025-11-04 0:58 ` Joel Fernandes
2025-11-04 13:42 ` Alexandre Courbot
2025-11-04 14:07 ` Miguel Ojeda
2025-11-04 14:35 ` Guillaume Gomez
2025-11-04 18:35 ` Miguel Ojeda
2025-11-04 19:06 ` Miguel Ojeda
2025-11-05 10:54 ` Guillaume Gomez
2025-11-11 20:32 ` Miguel Ojeda
2025-11-12 16:40 ` Guillaume Gomez
2025-11-04 13:52 ` Miguel Ojeda
2025-11-05 22:42 ` Joel Fernandes
2025-11-04 13:49 ` Danilo Krummrich
2025-10-30 19:06 ` [PATCH RFC 2/4] samples: rust: Add sample demonstrating C linked list iteration Joel Fernandes
2025-10-30 21:15 ` Danilo Krummrich
2025-10-30 22:09 ` Joel Fernandes
2025-11-01 3:52 ` Alexandre Courbot
2025-11-01 15:47 ` Miguel Ojeda
2025-10-30 19:06 ` [PATCH RFC 3/4] rust: drm: Add DRM buddy allocator bindings Joel Fernandes
2025-10-30 21:27 ` Danilo Krummrich
2025-10-30 22:49 ` Joel Fernandes
2025-10-31 9:25 ` Alice Ryhl
2025-11-04 22:57 ` Joel Fernandes
2025-11-01 5:08 ` Alexandre Courbot
2025-11-05 0:59 ` Joel Fernandes
2025-11-01 5:19 ` Alexandre Courbot
2025-10-30 19:06 ` [PATCH RFC 4/4] samples: rust: Add sample demonstrating DRM buddy allocator Joel Fernandes
2025-10-30 21:17 ` Danilo Krummrich
2025-10-31 16:42 ` Matthew Auld [this message]
2025-11-01 5:11 ` Alexandre Courbot
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=79bbbd8b-e60b-435b-82b6-ea59230997e2@intel.com \
--to=matthew.auld@intel.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=arighi@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=elle@weathered-steel.dev \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joel@joelfernandes.org \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=phasta@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.