Thu, Mar 05, 2026 at 03:37:29PM +0100, kuba@kernel.org wrote:

On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote:

quoted

Wed, Mar 04, 2026 at 07:15:22PM +0100, kuba@kernel.org wrote:

quoted

On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote:  

quoted

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.