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.)
next prev parent 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