On Thu, 9 Jul 2026 at 10:49, John Hubbard <[email protected]> wrote: > > On 7/8/26 5:16 PM, Alistair Popple wrote: > > On 2026-07-07 at 04:24 +1000, Danilo Krummrich <[email protected]> wrote... > >> On Mon Jul 6, 2026 at 7:35 PM CEST, Timur Tabi wrote: > >>> On Mon, 2026-07-06 at 15:34 +1000, Alistair Popple wrote: > >>>> @@ -38,6 +38,7 @@ pub(crate) fn get_param( > >>>> > >>>> let value = match getparam.param as u32 { > >>>> uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => pdev.resource_len(1)?, > >>>> + uapi::NOVA_GETPARAM_GPU_CHIPSET => reg_data.api.chipset() > >>>> as u64, > >>> > >>> Can we assign these IOCtl values to match Nouveau as much as possible? I > >>> think it would make > >>> everyone's life easier if we could use the same user-space > >>> tools/libraries for Nova that we do for > >>> Nouveau. > > > > I debated this, for the same reasons. However I came to the conclusion that > > it > > wouldn't make a big difference - Nouveau only has a handful of GETPARAMs and > > we already know we're going to need a lot more for Nova given the increased > > scope of features it needs to support. The rest of the API also needs to be > > sufficiently different so I didn't see any real practical advantage to > > keeping a > > couple of parameters the same as tools will need updating anyway. > > Unless all, or nearly all of the ioctl values would be the same, > there is absolutely no value in trying to make a small subset > match. > > Let's not get distracted by this. Nouveau is sunsetted and we need > to focus on building out Nova--without artificial constraints that > don't add real value. >
Yes it won't be possible to keep much aligned with nouveau's api, so let's no bother, nvk already has an abstraction in place that we can fill in at least. Dave.
