qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] qobject: Rewrite implementation of QDict for in-order tr


From: Peter Maydell
Subject: Re: [RFC PATCH] qobject: Rewrite implementation of QDict for in-order traversal
Date: Mon, 11 Jul 2022 12:15:22 +0100

On Mon, 11 Jul 2022 at 12:09, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Mon, Jul 11, 2022 at 11:32:35AM +0100, Peter Maydell wrote:
> > I'm pretty sure that nothing needs sparse array elements like
> > that. The major reason for the len-PROP field is an implementation
> > one: because there is currently no way for a QOM object to
> > say "call this method if somebody tries to set a non-existent
> > property", the way array properties work is that the 'set'
> > method for the len-PROP property is the place where we then
> > add the PROP[0], PROP[1], ... properties.
>
> Ahhh, I see what you mean. I totally missed this subtle detail.
>
> IIUC, there's essentially no such thing as array properties
> in QOM. 'prop[0]', 'prop[1]', 'prop[2]', etc are all simply
> scalar properties from QOM's, that just happen to follow a
> common naming scheme, but QOM doesn't care about that.

Yeah. The exception is the bit Markus pointed out where somebody
has later added special case support for setting "prop[*]" to
mean "whatever the next index is".

> > If we either had a "call this for any property set/get attempt
> > where there is no specific method set" or else had array
> > properties supported by the core QOM code, we could avoid
> > having to set len-PROP first.
>
> Techically arrays are already supported at the core QOM level, because
> you can use any QAPI type as a property.  The authz/list.c object
> has a 'rules' property that is an array of QAuthzListRule objects:
>
>   { 'struct': 'AuthZListProperties',
>     'data': { '*policy': 'QAuthZListPolicy',
>               '*rules': ['QAuthZListRule'] } }
>
> At the time I wrote that, we couldn't express it on the CLI though,
> without using JSON syntax for -object. I don't think we've ever
> made it possible to use the opts_visitor with non-scalar properties
> though.

Mmm, if we had started the array-property implementation starting
from a QAPI API (or even with the idea of setting properties from
command line arguments) and working from there we'd probably have ended
up with something different. The primary use case though has
never involved QAPI or the command line, it's just C code for setting
property values on devices created within QEMU.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]