The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alistair Popple" <apopple@nvidia.com>
Cc: "nova-gpu" <nova-gpu@lists.linux.dev>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"David Airlie" <airlied@gmail.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Benno Lossin" <lossin@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Eliot Courtney" <ecourtney@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl
Date: Wed, 26 Aug 2026 00:37:15 +0200	[thread overview]
Message-ID: <DKYDUOFB4C8P.3STNQMZY571XI@kernel.org> (raw)
In-Reply-To: <ao1AnG7fUhJ8a1U-@nvdebian.thelocal>

On Tue Aug 25, 2026 at 9:32 AM CEST, Alistair Popple wrote:
> On 2026-08-25 at 05:10 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
>> I don't think we are really concerned about running out of ioctls, but it seems
>> cleaner and more self-contained than having N ioctls for different info structs
>> and in the worst case having v2...vN info ioctls.
>
> But isn't v2...vN info ioctls dealt with in the usual way by extending the
> existing struct and bumping the size? That seems like a pretty clean and
> self-contained API to me.

To be clear, my main point is that having a single info ioctl with different
info types is more self-contained and provides more flexibility to introduce new
info types whenever we think it is warranted. Long term I expect it to be the
cleaner API.

>> It also allows us to define a new info type struct whenever we think something
>> is a new logical info group. Making it per ioctl will always raise the question
>> of "do we really need a new ioctl for this, can't we just fit it in X", which
>> over time tends to get messy.
>
> Doesn't that question also apply to adding GETPARAM N+1 though? If we're not
> worried about running out of top-level ioctls I don't understand why they
> are considered special enough to warrant the extra complexity of creating and
> decoding a hiearchy of sub-ioctls.

I think the code would be rather trivial:

	fn write_info<T: AsBytes>(info: &mut uapi::drm_nova_info, value: &T) -> Result {
	    let len = size_of_val(value).min(info.size);
	    let uptr = UserPtr::from_addr(info.data);
	    let mut writer = UserSlice::new(uptr, len).writer();

	    // Note: I made this up, as I think we want to add this method to
	    // `UserSliceWriter`, to avoid having to call `as_bytes()`.
	    writer.write_truncated(&value)?;
	    info.size = len;

	    Ok(())
	}

	match info.id {
	    uapi::DRM_NOVA_INFO_GPU => write_info(info, &uapi::drm_nova_gpu_info { ... })?,
	    uapi::DRM_NOVA_INFO_MEM => write_info(info, &uapi::drm_nova_mem_info { ... })?,
	    _ => return Err(EINVAL),
	}

Honestly, I think this is even less complicated that adding a new ioctl for a
new info struct.

And on the userspace side:

	fn query_info<T: Default>(fd: &DrmDevice, id: DrmNovaInfoId) -> Result<T> {
	    let mut value = T::default();
	    let mut info = drm_nova_info {
	        id: id.as_raw(),
	        size: size_of::<T>(),
	        data: ptr::from_mut(&mut value) as u64,
	    };

	    fd.ioctl(DRM_IOCTL_NOVA_INFO, &mut info)?;
	    Ok(value)
	}

	let gpu_info: drm_nova_gpu_info = query_info(&dev, DRM_NOVA_INFO_GPU)?;
	let mem_info: drm_nova_mem_info = query_info(&dev, DRM_NOVA_INFO_MEM)?;

(I pushed a few cleanups to drm-test, so this code should work.)

  reply	other threads:[~2026-08-25 22:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  5:06 [PATCH v4 0/7] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple
2026-08-11  5:06 ` [PATCH v4 1/7] gpu: nova-core: Add public driver API to nova-core Alistair Popple
2026-08-11  5:06 ` [PATCH v4 2/7] drm: nova: Add DRM registration data Alistair Popple
2026-08-11  5:06 ` [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI Alistair Popple
2026-08-24 14:49   ` M Henning
2026-08-24 19:24     ` Danilo Krummrich
2026-08-25  7:13       ` Alistair Popple
2026-08-25 12:03         ` Alistair Popple
2026-08-25 20:53           ` Danilo Krummrich
2026-08-25 20:53         ` Danilo Krummrich
2026-08-25 21:13           ` John Hubbard
2026-08-11  5:06 ` [PATCH v4 4/7] drm: nova: Add a GPU info ioctl Alistair Popple
2026-08-17 20:18   ` Danilo Krummrich
2026-08-21  5:10     ` Alistair Popple
2026-08-24 19:10       ` Danilo Krummrich
2026-08-25  7:32         ` Alistair Popple
2026-08-25 22:37           ` Danilo Krummrich [this message]
2026-08-24 19:34   ` Danilo Krummrich
2026-08-24 20:04     ` John Hubbard
2026-08-25  6:40       ` Alistair Popple
2026-08-11  5:06 ` [PATCH v4 5/7] drm: nova: Add usable VRAM size to " Alistair Popple
2026-08-11  5:06 ` [PATCH v4 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter Alistair Popple
2026-08-17 20:11   ` Danilo Krummrich
2026-08-21  5:13     ` Alistair Popple
2026-08-11  5:06 ` [PATCH v4 7/7] drm: nova: Expose a render node Alistair Popple

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=DKYDUOFB4C8P.3STNQMZY571XI@kernel.org \
    --to=dakr@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nova-gpu@lists.linux.dev \
    --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