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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).