Re: [PATCH v2] block: include child references in block device info

[Kevin Wolf <kwolf@redhat.com>]

Am 02.07.2025 um 11:39 hat Fiona Ebner geschrieben:
> Am 02.07.25 um 11:13 schrieb Kevin Wolf:
> > Am 01.07.2025 um 18:21 hat Fiona Ebner geschrieben:
> >> +##
> >> +# @BlockdevChild:
> >> +#
> >> +# @child: The name of the child, for example 'file' or 'backing'.
> >> +#
> >> +# @node-name: The name of the child's block driver node.
> >> +#
> >> +# Since: 10.1
> >> +##
> >> +{ 'struct': 'BlockdevChild',
> >> +  'data': { 'child': 'str',
> >> +            '*node-name': 'str' } }
> > 
> > Is node-name really optional? I don't think we have nodes without a node
> > name any more, do we?
> 
> I'm not aware of any, but @node-name in @BlockDeviceInfo is marked as
> optional too, so I went with that.
> 
> Looking at the git history, missing node-names are auto-generated since
> 15489c769b ("block: auto-generated node-names") or v2.5. The QAPI schema
> says @node-name was added before that in v2.0. Should it be made
> non-optional in @BlockDeviceInfo too?

Yes, I think this can be done.

Markus, a question about the future direction with such changes:
Currently, we only care about JSON level compatibility. In the future,
if we ever get native bindings for some programming languages (is anyone
still working on one?), I suppose a switch from something like
Option<String> to String could be considered incompatible. Would we
want to guarantee compatibility at that level then, or would
applications using the bindings just have to be updated?

Kevin