Thu, Mar 05, 2026 at 03:37:29PM +0100, [email protected] wrote: >On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote: >> Wed, Mar 04, 2026 at 07:15:22PM +0100, [email protected] wrote: >> >On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: >> >> On a second thought, if we merge multiple objects into one dump, how >> >> does this extend? I mean, the userspace has to check there are no extra >> >> attributes, as they may be used as a handle to another new object >> >> introduced in the future... Idk, it's a bit odd. >> > >> >That's true, the user space must be able to interpret the object >> >identifier. So if we extend the command to add more identifiers >> >we will have to add the bitmask to the dump request, and have >> >the user space tell the kernel which objects it can recognize. >> >I was just saying that we don't have to add such attribute now, >> >maybe leave a comment in a strategic place for our future selves? >> >> Or, alternatively, we can have per-object dumps as we have for all >> objects and command right now and leave things simple and >> straightforward? I mean, I don't really see a benefit of a single dump >> for more objects :/ > >What do you mean by straightforward, exactly? > >User will most likely want to see all resources of a device in a single >dump / command.
Hmm. We actually already have this for region and health reporter dumps. Only for params we have that separate. So let's do it for resource too. Thanks! > >The objects themselves are identical, they only differ by the handle, >and yet we'd have two separate commands to access them. > >It's as if we had separate GETLINK commands in rtnetlink for devices on >the PCIe bus vs connected via USB.
